Wow! Thanks for all that information. I am in exactly the same position, with the complexity of the externals. I will keep you posted, too, about my findings on submodules. One other drawback on subtrees, is that there is no GUI-solution I have tried (and I have tried GitExtension, SourceTree, TortoiseGit, EGit and GitGUI), which will offer a real nice view of the subtree structure. SourceTree come closest, but the drawback is that some of our users are using virtual Ubuntu. I don't know if the submodule presentation is any better in any of these tools, though.
Will report back as soon as I have some test projects up-and-running. Hopefully it may help others as well. And for the conversion, we have started out putting two test projects up in Git, which uses only one repository. One small project is new and the other is quite large but moved in manually from ClearCase, so I am aiming to start conversion from SVN in approx. two weeks. The large one is going to be split up, and splitting out a folder into a new repository is done the same way regardless of if you use the newly splitted repo as a submodule or a subtree, so it seems that this really doesn't affect the selection. 2014-12-30 10:31 GMT+01:00 Carl Cook <carl.c...@gmail.com>: > 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 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.
