Re: RFC: Between git-subtree and git-submodules

From: Santi Béjar <santi@agolina.net>
Date: Jul 25, 2010, 00:28 UTC
Message-ID: <AANLkTikwpruLt-D0tYn+eP5JpB1h0RD55+xr_7S+RfOa@mail.gmail.com>
In-Reply-To: <AANLkTinyjinsGS2ddyMOW=3zDN1ThJcpF+dc4cBE6L9D@mail.gmail.com>

Show 8 quoted lines

> With #3, I can see that you want something different than I do; you
> want to silently revert your own patches out of the submodule's
> history, when you upgrade the submodule to a new version.  Personally,
> I find this concept a bit objectionable (it's like "git merge -s
> ours"), but okay, it's pretty easy to implement, and you've submitted
> a patch to git-subtree that does it.  My question is: why would you
> want this?  Isn't it clearer to 'git revert' the patches you don't
> want?

While writing the docs for the --prune option I've found this sentence in git-subtree.txt:

	'git subtree merge --squash'
	always adjusts the subtree to match the exactly
	specified commit, even if getting to that commit would
	require undoing some changes that were added earlier.

I think this is not true, and it contradicts with what you've just said. Or I don't understand it correctly.

Thanks, Santi