[Question] Why sometimes the unmerged file doesn't contains any conflicts

[Question] Why sometimes the unmerged file doesn't contains any conflicts

[Johnny Lee]

Hi all,

Sometimes when I merge two branches, the unmerged files don't contain
any conflicts.
When I edit the file, I can't find any conflict information. Usually
all I have to do is manually "git add" them.

I do the merge with a clean workspace, all changes have been committed.
This doesn't happen all the time, usually the unmerged files contains
the correct conflict information inside.

Do you know what's going on here?
The version of my git is: 1.6.2.1

Thanks for your consideration.

Regards,
Johnny

-- 
we all have our crosses to bear

Re: [Question] Why sometimes the unmerged file doesn't contains any conflicts

[Junio C Hamano]

Johnny Lee <johnnylee194@gmail.com> writes:

> Sometimes when I merge two branches, the unmerged files don't contain
> any conflicts.
> When I edit the file, I can't find any conflict information. Usually
> all I have to do is manually "git add" them.
>
> I do the merge with a clean workspace, all changes have been committed.
> This doesn't happen all the time, usually the unmerged files contains
> the correct conflict information inside.
>
> Do you know what's going on here?
> The version of my git is: 1.6.2.1

Do you see something like these output when it happens?  If that is what
is happening to you, then it is perfectly normal, and the command even
gives explanations on what it did to you.  The only thing you need to do
is to read them ;-).

    $ git merge lt/pack-object-memuse
    Auto-merging builtin-pack-objects.c
    CONFLICT (content): Merge conflict in builtin-pack-objects.c
    Auto-merging builtin-rev-list.c
    CONFLICT (content): Merge conflict in builtin-rev-list.c
    Auto-merging list-objects.c
    CONFLICT (content): Merge conflict in list-objects.c
    Auto-merging list-objects.h
    CONFLICT (content): Merge conflict in list-objects.h
    Auto-merging revision.c
    Auto-merging revision.h
    Auto-merging upload-pack.c
    CONFLICT (content): Merge conflict in upload-pack.c
    Resolved 'builtin-pack-objects.c' using previous resolution.
    Resolved 'builtin-rev-list.c' using previous resolution.
    Resolved 'list-objects.c' using previous resolution.
    Resolved 'list-objects.h' using previous resolution.
    Resolved 'upload-pack.c' using previous resolution.
    Automatic merge failed; fix conflicts and then commit the result.

Notice the last set of lines "Resolved '%s' using previous resolution."

Another possibility is the common ancestor of the two branches did not
have the file in question and you added the same file on each of these
branches in a non-conflicting way.  That sometimes suggests a bad
workflow, but in an environment where two people independently pick up the
same patch on their branches and you end up merging with these two people,
it is also perfectly normal.

Re: [Question] Why sometimes the unmerged file doesn't contains any conflicts

[Johnny Lee]

I didn't see the log of "Resolved '%s' using previous resolution.".
I'm must having the latter situation.

Thanks Junio for pointing this out for me.

Cheers,
Johnny

On Mon, Apr 13, 2009 at 10:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Johnny Lee <johnnylee194@gmail.com> writes:
>
>> Sometimes when I merge two branches, the unmerged files don't contain
>> any conflicts.
>> When I edit the file, I can't find any conflict information. Usually
>> all I have to do is manually "git add" them.
>>
>> I do the merge with a clean workspace, all changes have been committed.
>> This doesn't happen all the time, usually the unmerged files contains
>> the correct conflict information inside.
>>
>> Do you know what's going on here?
>> The version of my git is: 1.6.2.1
>
> Do you see something like these output when it happens?  If that is what
> is happening to you, then it is perfectly normal, and the command even
> gives explanations on what it did to you.  The only thing you need to do
> is to read them ;-).
>
>    $ git merge lt/pack-object-memuse
>    Auto-merging builtin-pack-objects.c
>    CONFLICT (content): Merge conflict in builtin-pack-objects.c
>    Auto-merging builtin-rev-list.c
>    CONFLICT (content): Merge conflict in builtin-rev-list.c
>    Auto-merging list-objects.c
>    CONFLICT (content): Merge conflict in list-objects.c
>    Auto-merging list-objects.h
>    CONFLICT (content): Merge conflict in list-objects.h
>    Auto-merging revision.c
>    Auto-merging revision.h
>    Auto-merging upload-pack.c
>    CONFLICT (content): Merge conflict in upload-pack.c
>    Resolved 'builtin-pack-objects.c' using previous resolution.
>    Resolved 'builtin-rev-list.c' using previous resolution.
>    Resolved 'list-objects.c' using previous resolution.
>    Resolved 'list-objects.h' using previous resolution.
>    Resolved 'upload-pack.c' using previous resolution.
>    Automatic merge failed; fix conflicts and then commit the result.
>
> Notice the last set of lines "Resolved '%s' using previous resolution."
>
> Another possibility is the common ancestor of the two branches did not
> have the file in question and you added the same file on each of these
> branches in a non-conflicting way.  That sometimes suggests a bad
> workflow, but in an environment where two people independently pick up the
> same patch on their branches and you end up merging with these two people,
> it is also perfectly normal.
>
>



-- 
we all have our crosses to bear