needs merge

a merge results in multiple conflict files.

some of the files are resolved by editing and picking changes from both branches.

but some files I want to ignore the new changes and keep what was originally there. However, if I restore what was originally in the destination either by editing the destination and ending up with what i started with, or via git checkout on the file, i get

$ git commit my-file needs merge

how do i tell git that there is no merge to do and the (unchanged) working file is what i want to keep as the result of the merge?

i recall running into this a long time ago and i added blank line to the destination file and that made git happy, but maybe i shouldn't have to resort to that, yes?

thanks, -Len

Len Brown <len.brown@intel.com> writes:

Do you mean running

    $ git update-index my-file

to mark the path resolved?

yes, that allowed the git commit to complete, thanks.

however, when i then merged that branch into another there seem to be some phantom conflicts on the very same files. Do I understand all this output to mean that git attempted two different merges, and discarded the 1st attempt in favor of the second?

thanks, -Len

$ /lab/bin/git.merge acpica test
Merging test with ed03f430cdc8c802652467e9097606fedc2c7abc
Merging:
e3627f3165301a7d946c2dc40be93f744f441c30 Auto-update from upstream
ed03f430cdc8c802652467e9097606fedc2c7abc Pull pnpacpi into acpica branch
found 2 common ancestor(s):
0aec63e67c69545ca757a73a66f5dcf05fa484bf [PATCH] Fix posix-cpu-timers sched_time accumulation
ed349a8a0a780ed27e2a765f16cee54d9b63bfee [ACPI] fix pnpacpi regression resulting from ACPICA 20051117
  Merging:
  0aec63e67c69545ca757a73a66f5dcf05fa484bf [PATCH] Fix posix-cpu-timers sched_time accumulation
  ed349a8a0a780ed27e2a765f16cee54d9b63bfee [ACPI] fix pnpacpi regression resulting from ACPICA 20051117
  found 1 common ancestor(s):
  927fe18397b3b1194a5b26b1d388d97e391e5fd2 Pull 5165 into release branch
  Auto-merging arch/i386/kernel/mpparse.c
  Auto-merging include/asm-x86_64/mpspec.h
  Auto-merging arch/ia64/pci/pci.c
  Auto-merging drivers/acpi/utilities/utmisc.c
  CONFLICT (content): Merge conflict in drivers/acpi/utilities/utmisc.c
  Auto-merging include/acpi/acglobal.h
  CONFLICT (content): Merge conflict in include/acpi/acglobal.h
  Auto-merging drivers/acpi/scan.c
  Auto-merging drivers/acpi/pci_link.c

Merge bfaa3a0777f0fc3b82831cb1daf286f8ac3b4c8d, made by recursive.
 drivers/pnp/pnpacpi/rsparser.c |   48 +++++++++++++++++++++++++++++++++++++---
 1 files changed, 44 insertions(+), 4 deletions(-)
$

Len Brown <len.brown@intel.com> writes:

First of all, does the final merge result look correct, without conflict markers? I've slurped from your tree and tried the merge myself and it seems that both branches and the merge result of these branches have the conflicting path the same way, so I think it did the right thing for you, but I am just trying to make sure.

Not really.  This is Fredrik's "recursive" merge in action.

acpica (ed03f4) is merged into test (e3627f), but these two branches have criss-cross merge history and there are two equally valid common ancestors, 0aec63 and ed349a.

What it did was first to find a merge between these two common ancestors, during which it found conflicting merge on those paths.

It then used this merge result (with conflict markers still in them!) as the "virtual common ancestor" to merge the ed03f4 and e3627f commits; because both branches have resolved the conflicting part the same way earlier, this three-way merge cancels out the part that are marked with conflict markers in the virtual common ancestor (this is the cutest part of Fredrik merge algorithm).