threads / discuss / 18840

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

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

## tl;dr

3 messages between Apr 13, 2009 and Apr 13, 2009.

replies: 2people: 2as markdown or json

Johnny Lee· Apr 13, 2009, 02:35 UTC · lore
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
Junio C Hamano· Apr 13, 2009, 02:47 UTC · re: Johnny Lee · lore

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

Johnny Lee <johnnylee194@gmail.com> writes:
Show 11 quoted lines
> 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.

Johnny Lee· Apr 13, 2009, 03:43 UTC · re: Junio C Hamano · lore

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

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:
Show 49 quoted lines
> 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

← back to recent threads