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@xxxxxxxxx> wrote: > 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. > > -- we all have our crosses to bear -- 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