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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johnny Lee <johnnylee194@xxxxxxxxx> 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.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]