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