Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why your company shouldn't use Git submodules

codingkilledthecat.wordpress.com

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Why your company shouldn't use Git submodules

#21

Post by exDM69 »

etherealG wrote: post #11
exDM69 wrote: post #8

Earlier quoted context omitted.

No it would not be a good idea for the submodules to be always pointing to the HEAD of their repos. It might make sense for syncing with some very stable external projects but that is a very limited use case. I need to have a consistent set of all the submodules I'm working with. I need to reliably get the exact same versions of all the modules in the big repository. This allows me to do a "git bisect" to search for…

I think there's usefulness in being able to specify both things. I like the way it is now for a default, but like you say for some stable branch of another repository, it would be nice if submodules could be updated automatically.

The problem in automatically running "git submodule update" is that it might require network access, which may be down and/or slow. And the latest head might not be compatible with the rest of your software. Since there is no smart way of managing these problems, it's best not to do that implictly.

Re: Why your company shouldn't use Git submodules

#23

Post by exDM69 »

brazzy wrote: post #18
aoprisan wrote: post #17

So "if you forgot to run git submodule update, you’ve just reverted any submodule commits the branch you merged in might have made"... Yes, if you forget to type the correct commands then undesired effects will happen. Now that's a git design flaw? Give me a break.

So you'd also say that a car that explodes if you forget to press the "don't explode" button after refuelling is a perfectly good design? Even if you think you're perfect and never make mistakes, it's not a good idea to add easy opportunities to make mistakes.

Unlike an exploding car, Git has undo. See git reflog.

Re: Why your company shouldn't use Git submodules

#24

Post by sharken »

Agree with most of the posters, that Git submodules are very hard to work with.

The key to submodules is that you should not update them on a regular basis. A good example is the Gitflow project that uses the shFlags repo as a submodule.

A small gotcha is that you need to use --recursive when cloning the repo, so that you get the submodule cloned as well.

Re: Why your company shouldn't use Git submodules

#25

Post by moe »

Very good article. The question is, will it ever be fixed?

As it stands submodules don't even work sanely for the most trivial use-case of tracking a (slow changing) vendor-repo.

Whoever designed this (Linus?) had a real brainfart here.

Re: Why your company shouldn't use Git submodules

#26

Post by harshreality »

moe wrote: post #25

Very good article. The question is, will it ever be fixed? As it stands submodules don't even work sanely for the most trivial use-case of tracking a (slow changing) vendor-repo. Whoever designed this (Linus?) had a real brainfart here.

I wonder. How difficult can it be to mimic mercurial's subrepos?

http://blog.codekills.net/2011/07/14/nested-repository-handl...

Re: Why your company shouldn't use Git submodules

#28

Post by moe »

harshreality wrote: post #26
moe wrote: post #25

Very good article. The question is, will it ever be fixed? As it stands submodules don't even work sanely for the most trivial use-case of tracking a (slow changing) vendor-repo. Whoever designed this (Linus?) had a real brainfart here.

I wonder. How difficult can it be to mimic mercurial's subrepos? http://blog.codekills.net/2011/07/14/nested-repository-handl...

Yes!

That should be built straight into git. The abstraction leaks are no worse than with submodules (it's just making different trade-offs) but the usability is so much more sane, it's not funny.

The importance of having this in core-git can not be overstated. When it's not in core then it's not getting used. Case in point: count the number of projects on github using one of the external training wheels (subtree etc.).

Submodules has proven inadequate for reality (again: count the number of subprojects on github). I wish one of the core-dev's would make a kickstarter for a solution...

Re: Why your company shouldn't use Git submodules

#29

Post by valley_guy_12 »

exDM69 wrote: post #9

I've said this before but I'll say it again. Stay the hell away from Google's Repo tool. It's a half-baked badly maintained piece of ad-hoc software. It will completely destroy your git workflow. You'll also be married to the crappy review tool called Gerrit. Repo was made prior to Git submodules to do the exact same thing for Android. Now that Git has submodule support, Repo is useless. It does pretty much the same…

Repo seems to work the way it does on purpose:

"...the reason we made repo was because we didn't want to deal with commits in the super project, or trying to merge concurrent branches in the super project. Instead we wanted each subproject to use a floating branch as the revision it is tracking."

https://groups.google.com/d/msg/repo-discuss/ZpqOOE5mLXo/Sw0...

Re: Why your company shouldn't use Git submodules

#30

Post by mindjiver »

exDM69 wrote: post #9

I've said this before but I'll say it again. Stay the hell away from Google's Repo tool. It's a half-baked badly maintained piece of ad-hoc software. It will completely destroy your git workflow. You'll also be married to the crappy review tool called Gerrit. Repo was made prior to Git submodules to do the exact same thing for Android. Now that Git has submodule support, Repo is useless. It does pretty much the same…

Well, since the maintainer of repo wants to kill it off, it is perhaps not surprising that it is badly maintained at the moment.
Post reply on HN