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

On Sat, Jul 24, 2010 at 8:28 PM, Santi Béjar [off-list ref] wrote:

quoted

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