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

11–20 of 46 posts

Re: Why your company shouldn't use Git submodules

#11

Post by etherealG »

exDM69 wrote: post #8
rogerbinns wrote: post #4

I've also tried and failed several times to use submodules. Live would be a lot easier for my situations if the parent could always point to the head of the child instead of a specific revision.

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.

Re: Why your company shouldn't use Git submodules

#13

Post by saurik »

ryanpetrich wrote: post #7
saurik wrote: post #6

There are serious problems with git submodules. This article, however, is simply concentrating on "you can forget to do X or not understand Y, in which case you can cause yourself minor irritations", which is just silly: if you understand how to use submodules all of the problems in this article go away and get replaced with more serious issues like "the submodule update mechanism doesn't get rid of obsolete submodul…

git submodule add will create a submodule in a subfolder.

Ah, touche: I forgot that that one was just an issue with the tool and not a fundamental limitation. (Sadly, the same kind of "that isn't a real problem: just a 'you don't know enough'" that I'm complaining about from the article ;P.)

Re: Why your company shouldn't use Git submodules

#14

Post by alexchamberlain »

buddydvd wrote: post #10

Git's submodule feature definitely has rough edges, however, I think the benefits outweigh the cons. One of the best benefits I see is that submodules make embedding forks more manageble. For example, when you include an open source library in your own project, it's common that you'd want to modify the library in some way. If you commit the modified library into your own project's repository, you'll have a harder tim…

If you want to make changes to the upstream, I suggest adding an extra mirror in between the upstream and the repo you want to add the submodule in. That way, you can maintain your version without worrying about how your other code is affected. Only after it is tested do you then merge it into your other repo.

Re: Why your company shouldn't use Git submodules

#15

Post by pyre »

ryanpetrich wrote: post #7
saurik wrote: post #6

There are serious problems with git submodules. This article, however, is simply concentrating on "you can forget to do X or not understand Y, in which case you can cause yourself minor irritations", which is just silly: if you understand how to use submodules all of the problems in this article go away and get replaced with more serious issues like "the submodule update mechanism doesn't get rid of obsolete submodul…

git submodule add will create a submodule in a subfolder.

I think that the issue is that always has to be relative to the root directory. You can't do something like:

  % cd subpath
  % git submodule add

Re: Why your company shouldn't use Git submodules

#16

Post by pyre »

saurik wrote: post #6

There are serious problems with git submodules. This article, however, is simply concentrating on "you can forget to do X or not understand Y, in which case you can cause yourself minor irritations", which is just silly: if you understand how to use submodules all of the problems in this article go away and get replaced with more serious issues like "the submodule update mechanism doesn't get rid of obsolete submodul…

  > a major step down from Subversion, where the subtree
  > repository support
You could always checkout git-subtree. The functionality is there under the hood in git (git-subtree is literally a shell script, though not a minor one).

Re: Why your company shouldn't use Git submodules

#17

Post by aoprisan »

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.

Re: Why your company shouldn't use Git submodules

#18

Post by brazzy »

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.

Re: Why your company shouldn't use Git submodules

#19

Post by buddydvd »

alexchamberlain wrote: post #14
buddydvd wrote: post #10

Git's submodule feature definitely has rough edges, however, I think the benefits outweigh the cons. One of the best benefits I see is that submodules make embedding forks more manageble. For example, when you include an open source library in your own project, it's common that you'd want to modify the library in some way. If you commit the modified library into your own project's repository, you'll have a harder tim…

If you want to make changes to the upstream, I suggest adding an extra mirror in between the upstream and the repo you want to add the submodule in. That way, you can maintain your version without worrying about how your other code is affected. Only after it is tested do you then merge it into your other repo.

The projects I add as submodules are all hosted on Github. For those that require modification, I would fork (mirror) the project, commit the changes to my fork, and add the fork as a submodule to the parent project I'm working on. So, yes, I do add an extra mirror in between but it's really because I lack contributor permission to the main repository.

Also, if repository A and B reference repository C as a submodule and I update repository C for A, B would not be affected since submodule references are just commit IDs. There's no need to create two additional mirrors (C-for-A and C-for-B) if that's what you meant.

Re: Why your company shouldn't use Git submodules

#20

Post by buddydvd »

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.

You could specify a directory in .gitignore and create a script that clones/pulls the repository of your choosing into that directory.
Post reply on HN