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

From: Avery Pennarun <apenwarr@gmail.com>
Date: Jul 26, 2010, 05:02 UTC
Message-ID: <AANLkTim_XeoEeRBa8VCLMn=rbFb3mvKm6OJ=M7D6YJBz@mail.gmail.com>
In-Reply-To: <AANLkTikwpruLt-D0tYn+eP5JpB1h0RD55+xr_7S+RfOa@mail.gmail.com>

On Sat, Jul 24, 2010 at 8:28 PM, Santi Béjar <santi@agolina.net> wrote:

Show 19 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.

I agree that this is a bit unclear. Basically it rewinds the *base* of the subtree to match the commit you specify. Patches you've applied locally are not removed.

What it actually does is it creates a new commit that applies the following patch:

    git diff oldbase newbase

If you've made any of your own patches that conflict with this, it'll generate the conflict and then stop. Otherwise it'll merge in your changes as you might expect.

Have fun,

Avery