git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Johnny Lee <johnnylee194@gmail.com>
Date
Apr 13, 2009, 03:43 UTC
Message-ID
<488807870904122043q5bf3884fu1012446e1e71c048@mail.gmail.com>
In-Reply-To
<7vk55pxoax.fsf@gitster.siamese.dyndns.org>

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
Previous: Junio C Hamano
Message 3 of 3 in “[Question] Why sometimes the unmerged file doesn't contains any conflicts”
  1. Johnny LeeApr 13, 2009
  2. Junio C HamanoApr 13, 2009
  3. Johnny LeeApr 13, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.