Mattias, one thing I should mention... there is a noticeable difference
between submodules and svn externals regarding the development process.

Using svn externals, if you point to trunk of an external, and someone else
commits to that external, you see the change as soon as you do an svn up
(or as soon as the continuous integration server detects the commit and
does a clean build).

Using git submodules, it takes user action to update the submodules (i.e.
"git submodule update") to take any changes recently committed to a
submodule.

Depending on your current development process, this might be a significant
difference. I am considering making my build server automatically do a git
submodule update on any commit to a submodule.

On 30 December 2014 at 11:15, Mattias Vannergård <
mattias.vannerg...@gmail.com> wrote:

> 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 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.

Reply via email to