On Sat, Jul 24, 2010 at 8:28 PM, Santi Béjar <santi@xxxxxxxxxxx> wrote:
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html