Why your company shouldn’t use Git submodules « Coding Killed the Cat


58 bookmarks. First posted by raphman april 2012.


It’s after you’ve actually worked with submodules for a while that you start to notice just how half-baked Git’s submodules system really is.
git  advanced  development 
july 2014 by jpstacey
'It is not uncommon at all when working on any kind of larger-scale project with Git to find yourself wanting to share code between multiple different repositories – whether it be some core system among multiple different products built on top of that system, or perhaps a shared utility library between projects. At first glance, Git submodules seem to be the perfect answer for this: they come built-in with Git, they act like miniature repositories (so people are already familiar with how to change them), et cetera. They even support pointing at specific versions of the shared code, so if one project doesn’t want to deal with integrating the “latest and greatest” version, it doesn’t have to. It’s after you’ve actually worked with submodules for a while that you start to notice just how half-baked Git’s submodules system really is.'
git  source-control  revision-control  submodules  storage 
april 2014 by jm
An argument against Git submodules that hinges on how easy it is to unintentionally revert a submodule update or forget to pull one in. Interface problems to be sure but I alleviate these concerns by pretty much always making submodule changes in their own commits and building tools that include `git submodule update --init`.
git  submodule 
january 2014 by rcrowley
A programmer had a version control problem and said, “I know, I’ll use submodules.” Now they have two problems. It is not uncommon at all when working on any kind of larger-scale…
from readability
august 2013 by michaelfox
via Pinboard Network RSS Improver http://pipes.yahoo.com/pipes/pipe.info?_id=b22b9c9acee5906aab7e8a7645a247a9 'It is not uncommon at all when working on any kind of larger-scale project with Git to find yourself wanting to share code between multiple different repositories – whether it be some core system among multiple different products built on top of that system, or perhaps a shared utility library between projects. At first glance, Git submodules seem to be the perfect answer for this: they come built-in with Git, they act like miniature repositories (so people are already familiar with how to change them), et cetera. They even support pointing at specific versions of the shared code, so if one project doesn’t want to deal with integrating the “latest and greatest” version, it doesn’t have to. It’s after you’ve actually worked with submodules for a while that you start to notice just how half-baked Git’s submodules system really is.'
iftttFeedly 
august 2013 by earth2marsh
A programmer had a version control problem and said, “I know, I’ll use submodules.” Now they have two problems.

It is not uncommon at all when working on any kind of larger-scale project with Git to find yourself wanting to share code between multiple different repositories – whether it be some core system among multiple different products built on top of that system, or perhaps a shared utility library between projects.

At first glance, Git submodules seem to be the perfect answer for this: they come built-in with Git, they act like miniature repositories (so people are already familiar with how to change them), et cetera. They even support pointing at specific versions of the shared code, so if one project doesn’t want to deal with integrating the “latest and greatest” version, it doesn’t have to.

It’s after you’ve actually worked with submodules for a while that you start to notice just how half-baked Git’s submodules system really is.
git 
april 2013 by jfentress
A programmer had a version control problem and said, “I know, I’ll use submodules.” Now they have two problems.

It is not uncommon at all when working on any kind of larger-scale project with Git to find yourself wanting to share code between multiple different repositories – whether it be some core system among multiple different products built on top of that system, or perhaps a shared utility library between projects.

At first glance, Git submodules seem to be the perfect answer for this: they come built-in with Git, they act like miniature repositories (so people are already familiar with how to change them), et cetera. They even support pointing at specific versions of the shared code, so if one project doesn’t want to deal with integrating the “latest and greatest” version, it doesn’t have to.

It’s after you’ve actually worked with submodules for a while that you start to notice just how half-baked Git’s submodules system really is.
git  git:submodules 
april 2013 by sechilds
Of course, if you forget to update your submodule to the new version, it’s then quite easy to commit the old submodule version in your next parent repository commit – thus effectively reverting the submodule bump by the other developer. Given that submodule changes only show up as 2 commit lines in a diff, it’s not hard for such a change to slip by (especially if you’re a developer that tends to use git add . or git commit -a most of the time).
git 
january 2013 by arnalyse
@durden20 http://t.co/bNmFwQJb
Just thought I'd offer.
git  from instapaper
december 2012 by durden
Push changes from the submodule and not the parent repository? No one knows to use your new submodule changes. Push changes from the parent repository and not the submodule? Congratulations, no one can use your new commits because they don’t have the right submodule commit available to check out.
kb_cpu  git  programming 
june 2012 by rootis0
Why your company shouldn’t use Git submodules
ididnotknowthat  from twitter
june 2012 by JimRoepcke
A programmer had a version control problem and said, “I know, I’ll use submodules.” Now they have two problems.

It is not uncommon at all when working on any kind of larger-scale project with Git to find yourself wanting to share code between multiple different repositories – whether it be some core system among multiple different products built on top of that system, or perhaps a shared utility library between projects.

At first glance, Git submodules seem to be the perfect answer for this: they come built-in with Git, they act like miniature repositories (so people are already familiar with how to change them), et cetera. They even support pointing at specific versions of the shared code, so if one project doesn’t want to deal with integrating the “latest and greatest” version, it doesn’t have to.

It’s after you’ve actually worked with submodules for a while that you start to notice just how half-baked Git’s submodules system really is.
Git 
may 2012 by GameGamer43
on not using submodules
git  versioncontrol 
april 2012 by jshwlkr
RT : Why your company shouldn't use Git submodules
from twitter
april 2012 by paulboxley
The problems with git submodules and alternative tools http://t.co/2FpAbc1s
from instapaper
april 2012 by hiessu
Why your company shouldn’t use Git submodules
git  tips 
april 2012 by robertvesco
At first glance, Git submodules seem to be the perfect answer for this: they come built-in with Git, they act like miniature repositories (so people are already familiar with how to change them), et cetera. They even support pointing at specific versions of the shared code, so if one project doesn’t want to deal with integrating the “latest and greatest” version, it doesn’t have to.

It’s after you’ve actually worked with submodules for a while that you start to notice just how half-baked Git’s submodules system really is.
git  programming  versionc 
april 2012 by zdw
Why your company shouldn’t use Git submodules « Coding Killed the Cat:
development  git  programming  reference 
april 2012 by jschoolcraft
Why your company shouldn't use Git submodules ()
from twitter_favs
april 2012 by derrickreimer