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

From: Avery Pennarun <apenwarr@gmail.com>
Date: Jul 24, 2010, 00:57 UTC
Message-ID: <AANLkTinyjinsGS2ddyMOW=3zDN1ThJcpF+dc4cBE6L9D@mail.gmail.com>
In-Reply-To: <AANLkTi=tDRfgzzcbp0jV=+hQ+Cs2fhNF0vK8JL1COoFu@mail.gmail.com>

On Fri, Jul 23, 2010 at 8:13 PM, Santi Béjar <santi@agolina.net> wrote:

Show 21 quoted lines

>  First my requirements:
>
> 1) Everything[a] must be available from the same repository/branch (so I'm not
>   worried about repository size)
> 2) The history must be as clean as possible
> 3) The directory content must be equal to the external module, at least when
>   you add/update it[b]
> 4) The external module should be able to switch back and forth between
>   different versions.
>
> [a] Everything means all that you need to checkout all the commits in the
> superproject not in the submodule.
> [b] A consequence of #3 is that I lose all
> change I've made in the subdirectory, if they are important I have to extract
> them, apply them and add the module back.
>
> git-submodule is rule out because of #1 but accomplish #2, #3 and
> #4. git-subtree is rule out because of #2 (even with --squash).
> [It fails at] #3 and #4
> without --squash but accomplish #1 and #4 with --squash. So I need something
> in between or a mixture of both.

I admit to having had some trouble parsing the above, so I moved some punctuation marks around. Please let me know if I've made a mistake.

If I understand correctly, you're claiming (indirectly) that git-subtree without --squash does not accomplish #1. I don't see how this is the case. Am I misreading? I think git-subtree accomplishes #1 in both modes.

I don't understand what you mean when you say (#2) git-subtree doesn't keep your history "as clean as possible." What is "as clean as possible" and what part of git-subtree's history results don't you like? (Of course it's very different with and without --squash.)

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?

And for #4, it's true that git-subtree without --squash does not allow you to easily rewind to an older version of the submodule, while with --squash it does.

It sounds to me like, if we added your patch to git-subtree, then git-subtree --squash would solve #1, #3, and #4. And maybe we could fix #2 as well. Correct?

Thanks,

Avery