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

[Johnny Lee <johnnylee194@gmail.com>]

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