Hi Mattias, It is interesting that you have posted those links about why submodules are inferior to subtrees. I also read those links before doing any testing myself, and concluded that submodules were indeed not the answer.
However, after then testing both subtrees and submodules, it turns out that submodules look ideal for my needs (projects with up to 30 externals, and deeply nested externals). Yes, it is a concern that a.) local changes can be accidentally erased, and b.) repositories could end up in invalid states. However, I think after getting used to submodules (and I've only just started converting all my projects now), I will quickly learn to avoid these pitfalls. I work with another team who recently converted from svn externals to git submodules, and after a few hard lessons they are now really happy with things. By the way, I'm reasonably sure that any changes wiped out by submodule updates can be recovered from the reflog. In terms of scripting, yes, I do have scripts to ensure that tagged versions of projects have the correct revisions/tags of each submodule. This is not a pre-commit hook, but I imagine that would be possible if required. I also considered a third approach (after extensively testing subtrees and discovering the subsequent shortfalls), which is a do-it-yourself approach. I.e. to have CMake or another build system manage the externals. This can work (e.g. you can have git repos inside another git repo, as long as you remember to add the subproject to the .gitignore file of the superproject). But, then you also have to hand-craft a mechanism for specifying the revision that each subproject should be at, and then somehow have this information "locked" when it comes time to tag the superproject... and after all of that, I realised that submodules does all of this for free. It's early days for me right now... I'm still converting the projects over from svn to git, but it really looks like git submodules are going to work. I'll keep you posted! On 30 December 2014 at 10:08, Mattias Vannergård < mattias.vannerg...@gmail.com> wrote: > OK! > > Submodules is another approach (IMHO). I am also replacing svn externals, > but we wanted to get away from the unsafe/unstable updates, along with > adding gerrit/git-review and git-flow. I guess you are not using submodules > without some scripting/hooks to ensure you have the right submodule > version? And pushing the submodule recursively as well (bottom-up)? > > Reading up on: > [1] Alternatives To Git Submodule: Git Subtree > <http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/> > [2] Why your company shouldn’t use Git submodules > <https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/> > [3] Git Submodules are not SVN externals > <http://alexking.org/blog/2012/03/05/git-submodules-vs-svn-externals> > > I do see that submodules have drawbacks, but I currently don't see which > is worse - implementing a script for recursing subtrees or implementing > hooks to ensure the submodules are not overwritten and/or superprojects not > left in an incomplete state. > > If you'd like to share more of your experience in selecting submodules to > replace SVN externals, I'd be grateful. Your input so far makes me want to > set up two test projects, one using subtrees and one using submodules... In > fact so much I will start right away. :) > > Thanks > /Mattias > > 2014-12-30 9:22 GMT+01:00 Carl Cook <carl.c...@gmail.com>: > >> Hi Mattias, >> >> I haven't found another approach unfortunately. In fact, I am now using >> submodules instead of subtrees, as I've found submodules to do what I need >> (thankfully)... which is to be a replacement for svn externals. >> >> Good luck! >> Carl >> >> On 29 December 2014 at 16:34, Mattias Vannergård < >> mattias.vannerg...@gmail.com> wrote: >> >>> Hi Carl! >>> >>> I am looking into a set up for this, too. >>> >>> As far as I have found out, you need to script a "recursive subtree >>> pull" yourself, using the info stored in .gittrees >>> >>> Have you yet found another solution? >>> >>> BR >>> /Mattias >>> >>> Den tisdagen den 7:e oktober 2014 kl. 12:31:24 UTC+2 skrev Carl Cook: >>> >>>> Just some more info, today I discovered the foreach command that comes >>>> with git submodule. >>>> >>>> So, is there a subtree equivalent? >>>> >>>> On Monday, 6 October 2014 11:34:49 UTC+2, Carl Cook wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Does anyone know if it's possible to do a git subtree pull for all >>>>> subtrees in the repository? >>>>> >>>>> I can do this via CMake, but it would be handy to have this in git >>>>> (although maybe this is going beyond what git should be expected to do). >>>>> >>>>> Thanks, >>>>> Carl >>>>> >>>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Git for human beings" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/git-users/GdimsW586Mk/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> git-users+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Git for human beings" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/git-users/GdimsW586Mk/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> git-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Git for human beings" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/git-users/GdimsW586Mk/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
