Nanako Shiraishi [off-list ref] writes:
Quoting Junio C Hamano [off-list ref]:
quoted
* 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.
Quoting Junio C Hamano [off-list ref]:
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.
I do not know if "I do not understand what they did well enough" is the only reason people would want to use that feature. Isn't it better to let people decide that for themselves?
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.
I think such a documentation will help people to decide if 'theirs' option makes sense for their workflow.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
On Fri, Jul 18, 2008 at 06:20:10PM +0900, Nanako Shiraishi wrote:
I do not know if "I do not understand what they did well enough" is the only reason people would want to use that feature. Isn't it better to let people decide that for themselves?
It is dangerous to introduce new options just because we think someone,
sometimes might find it useful, especially if they potentially encourage
a bad workflow. Adding options and commands is expensive since it
complicates the UI further, thus we should add further only when we have
good reason for it.
quoted
That also was the reason I did not add any documentation to it.
I was actually looking for something like this based on some question on
#git (about git pull -s theirs possibility), and did stumble upon these
patches, but quickly gave up on them since it wasn't immediately clear
for me from the patch description exactly how the workflow looks like
(it doesn't really seem to work like the opposite of -s ours nor is it a
separate strategy... huh) and the options were completely undocumented.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce