On Sat, Jul 24, 2010 at 2:57 AM, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: > 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. Yes, git-subtree accomplishes #1 in both modes. --squash only applies to #4. > > 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 git-subtree you always have the subtree history (even if it is squashed). So when you merge a second time the submodule you get the always the history of the subtree (even with --squash). So you basically always have at least two branches while examining the history. Compare this squashed history: $ git log --graph --oneline * bb2dc25 (HEAD, master) Merge commit '08b917ee90ecfd7b666364fe4ebb92aee5cdd2f7' |\ | * 08b917e Squashed 'latex/' changes from ea35faf..895916a * | 9de91f1 Merge commit 'b1b4c36bb8358582a6a20bb500bf98421428e2ca' as 'latex' |\| | * b1b4c36 Squashed 'latex/' content from commit ea35faf * ea35faf Indent, whitespaces,... with this pruned history: $ git log --graph --oneline * 8703aec (HEAD, master) Subtree 'latex/': 895916a Add files subcommand * a942284 Subtree 'latex/': ea35faf Indent, whitespaces,... * ea35faf Indent, whitespaces,... But I understand that it can only be this way because of #3. > > 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? I prefer to do all the modifications in an external repository, even if at the end it is really a fork of the upstream repository. I think the proper place to modify the files in a subtree is in an external repository. > > 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? My patch does not change the behavior of --squash, it adds --prune. Thanks, Santi -- 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