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

On Fri, Jul 23, 2010 at 8:13 PM, Santi Béjar [off-list ref] 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