From: Junio C Hamano <gitster@pobox.com>
To: Avery Pennarun <apenwarr@gmail.com>
Cc: Nanako Shiraishi <nanako3@lavabit.com>,
Marc Fournier <marc.fournier@camptocamp.com>,
git@vger.kernel.org
Subject: Re: git-subtree: directory mismatch
Date: Wed, 25 Nov 2009 12:20:21 -0800 [thread overview]
Message-ID: <7vpr76uzju.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <32541b130911251148v70a5dc77k9936881d0b382ec2@mail.gmail.com> (Avery Pennarun's message of "Wed\, 25 Nov 2009 14\:48\:13 -0500")
Avery Pennarun <apenwarr@gmail.com> writes:
>> Look at http://github.com/gitster/git/commits/jc/merge-theirs/
>
> 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.
next prev parent reply other threads:[~2009-11-25 20:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-24 19:53 git-subtree: directory mismatch Marc Fournier
2009-11-24 21:48 ` Avery Pennarun
2009-11-24 23:08 ` Nanako Shiraishi
2009-11-25 18:28 ` Avery Pennarun
2009-11-25 19:31 ` Junio C Hamano
2009-11-25 19:48 ` Avery Pennarun
2009-11-25 20:20 ` Junio C Hamano [this message]
2009-11-25 23:17 ` Johannes Schindelin
2009-11-25 23:20 ` Avery Pennarun
2009-11-25 23:41 ` Björn Steinbrink
2009-11-25 23:45 ` Avery Pennarun
2009-11-25 14:32 ` Marc Fournier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vpr76uzju.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=apenwarr@gmail.com \
--cc=git@vger.kernel.org \
--cc=marc.fournier@camptocamp.com \
--cc=nanako3@lavabit.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox