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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 13, 2009, 02:47 UTC
Message-ID: <7vk55pxoax.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <488807870904121935nab40117n56070570ecd31aa7@mail.gmail.com>

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.