Nanako Shiraishi <nanako3@xxxxxxxxxxx> writes: > Quoting Junio C Hamano <gitster@xxxxxxxxx>: > >> * xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits >> + Teach git-merge -X<option> again. >> + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next >> + builtin-merge.c: use parse_options_step() "incremental parsing" >> machinery >> + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next >> >> This needs to be merged to master iff/when merge-theirs gets merged, >> but I do not think this series is widely supported, so both are on hold. > > Why do you say it is not widely supported? I may be wrong but I think > you developed these patches after somebody from the mailing list asked > for this feature. Well, for one thing, I do not believe in their cause. As I wrote in the log messages for these commits (actually not these above which is a series for merge fixup, but the other topic), I do not think it is a sensible thing to say "let's take as much automerge results as possible to salvage our changes where they do not overlap with what the upstream did, but I would give up our changes to places that the upstream also touched, because I do not understand what they did well enough to be able to resolve the merge conflicts correctly", and "merge -Xtheirs" is exactly that. That also was the reason I did not add any documentation to it. But I do like the change to the infrastructure to allow passing strategy-specific options through git-merge and git-pull. Perhaps I should write something up, if only to salvage that -X<option> part, even though I am very much inclined to discard -Xtheirs (and -Xours) part. -- 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
