I also tried simply searching for things like 'git "-xsubtree"' in
google, with no luck. But thanks for the link.
I didn't _find_ the link ;-) I just pushed it out a few minutes ago,
after looking for strings that appear in messages of these commits. The
series was done over a few weeks, and would have been very painful to find
from the gmane archive.
- What was the reason this never got merged? What changes are needed
to rectify that?
I do not remember there was any real reason. I do remember some people
didn't like -X<option> syntax but I don't think there was any solid
counterproposal to achieve a similar goal to satisfy the need to pass
arbitrary parameters to the merge strategy backends.
- Considering the earlier discussion, do we want to leave out the
actual -Xtheirs feature and just have -Xours and -Xsubtree?
Both -Xtheirs and -Xours have the same degree of badness in the context of
"source code management", but there was a real-world use case that would
have benefitted from -Xours recently.
cf. http://thread.gmane.org/gmane.comp.version-control.git/131902/focus=132920
If -Xours goes in, so should -Xtheirs, I think, because Peter's "web tree"
example could merge in both ways (i.e. he could be pulling from web tree
into his private area and then cleaning things up before pushing the
result back).
- If I rebase them and the changes turn out to be minimal, do they
still need a signed-off-by Junio?
"minimal" by definition means that you ased your work on mine and I still
have the copyright to the change as a co-author together with you. We
both need to certify that the change is made under DCO.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:47:46
Hi,
On Wed, 25 Nov 2009, Junio C Hamano wrote:
I do remember some people didn't like -X<option> syntax but I don't
think there was any solid counterproposal to achieve a similar goal to
satisfy the need to pass arbitrary parameters to the merge strategy
backends.
I took exception to the awkward way to specify the option. A strong hint
just how awkward -X<option> is: it is hard to implement using
parse-options.
There is no real reason to do it properly, i.e. with an option
--merge-option <option> or --backend-option <option> or -X <option> (even
if "-X" is not really an expressive name, to be real honest).
BTW the same goes for -S<string>, but unfortunately, we have to keep it
to maintain backwards compatibility.
Ciao,
Dscho
On Wed, Nov 25, 2009 at 6:17 PM, Johannes Schindelin
[off-list ref] wrote:
On Wed, 25 Nov 2009, Junio C Hamano wrote:
quoted
I do remember some people didn't like -X<option> syntax but I don't
think there was any solid counterproposal to achieve a similar goal to
satisfy the need to pass arbitrary parameters to the merge strategy
backends.
I took exception to the awkward way to specify the option. A strong hint
just how awkward -X<option> is: it is hard to implement using
parse-options.
I read the earlier thread and I still don't quite understand this
point. What makes it difficult? X seems just like any other option
that takes a string parameter (which is easily supported by getopt at
least; I haven't played with parse_options but I certainly hope it's
as good as getopt).
The string parameter (say, $x) is translated directly into "--$x" and
passed as exactly one argument of the argv array to the subprogram.
Easy, right? Plus Junio already wrote a patch to do it (which I'm in
the process of forward-porting) and it seems pretty straightforward.
Perhaps I'm missing something.
Thanks,
Avery
From: Björn Steinbrink <hidden> Date: 2016-06-15 22:47:46
On 2009.11.25 18:20:45 -0500, Avery Pennarun wrote:
On Wed, Nov 25, 2009 at 6:17 PM, Johannes Schindelin
[off-list ref] wrote:
quoted
On Wed, 25 Nov 2009, Junio C Hamano wrote:
quoted
I do remember some people didn't like -X<option> syntax but I don't
think there was any solid counterproposal to achieve a similar goal to
satisfy the need to pass arbitrary parameters to the merge strategy
backends.
I took exception to the awkward way to specify the option. A strong hint
just how awkward -X<option> is: it is hard to implement using
parse-options.
I read the earlier thread and I still don't quite understand this
point. What makes it difficult?
I guess it's -Xfoo vs. -X foo (note the space). Same deal with log
-S<string>. "git log -S foo" would look for an empty string (I guess)
being added/removed in some commit in foo's history, while "git log
-Sfoo" looks for "foo" being added/remove in HEAD's history.
Björn
On 2009.11.25 18:20:45 -0500, Avery Pennarun wrote:
quoted
I read the earlier thread and I still don't quite understand this
point. What makes it difficult?
I guess it's -Xfoo vs. -X foo (note the space). Same deal with log
-S<string>. "git log -S foo" would look for an empty string (I guess)
being added/removed in some commit in foo's history, while "git log
-Sfoo" looks for "foo" being added/remove in HEAD's history.
Oh. Ouch. Isn't it standard for options-that-take-string-parameters
to always *require* that parameter? This seems to be how getopt
works. Basically "-X foo" is the same as "-Xfoo" in that system.
If parse_options doesn't already do this, should I try to add it somehow?
Avery