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

[Avery Pennarun <apenwarr@gmail.com>]

On Fri, Jul 23, 2010 at 8:13 PM, Santi Béjar <santi@agolina.net> wrote:
>  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