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

Mastering Git submodules

medium.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: Mastering Git submodules

#21

Post by tokenizerrr »

Navarr wrote: post #14

> For instance, themes and plugins for Wordpress, Magento, etc. are often de facto installed by their mere presence at conventional locations inside the project tree, and this is the only way to “install” them. > In such a situation, going with submodules (or subtrees) probably is the right solution As a Magento Developer, I'm afraid submodules wouldn't work for Magento plugins. As they unfortunately have to be insta…

The last time I worked on Magento, and it has been a while, we would install the dependency in a single directory, and then you'd run a tool over it to "install" it into the proper locations. Sadly I cannot remember the name of this tool, but from memory it seems you could combine that with submodules?

We used this so we could track an entire extension's source code in Git, and move them around easily.

edit: I was thinking of modman

Re: Mastering Git submodules

#22

Post by icebraining »

Navarr wrote: post #14

> For instance, themes and plugins for Wordpress, Magento, etc. are often de facto installed by their mere presence at conventional locations inside the project tree, and this is the only way to “install” them. > In such a situation, going with submodules (or subtrees) probably is the right solution As a Magento Developer, I'm afraid submodules wouldn't work for Magento plugins. As they unfortunately have to be insta…

Can't you use symlinks?

Re: Mastering Git submodules

#23

Post by e40 »

jawngee wrote: post #20

I swear I must be the only person in the world that has no problems using submodules and I use them constantly . It puzzles me that people have such problems with it, which I guess illustrates how unreliable anecdotal evidence really is. I've had detached head issues, but nothing that didn't take a minute or two to solve. It might be that I'm using SourceTree exclusively, so maybe SourceTree is hiding away the painfu…

which I guess illustrates how unreliable anecdotal evidence really is.

Or, maybe your use case skirts around the problems?

Re: Mastering Git submodules

#24

Post by nailer »

jawngee wrote: post #20

I swear I must be the only person in the world that has no problems using submodules and I use them constantly . It puzzles me that people have such problems with it, which I guess illustrates how unreliable anecdotal evidence really is. I've had detached head issues, but nothing that didn't take a minute or two to solve. It might be that I'm using SourceTree exclusively, so maybe SourceTree is hiding away the painfu…

Same here on both counts - have been using ST as my main git interface since 2011 (I still use command line for git init, reflog, and checking stuff remotely on VMs, and git bfg if someone committed a credential), and using submodules across a wide variety of projects. I've never had a problem, and only avoid subtrees to be nice to my colleagues that have had problems

Re: Mastering Git submodules

#25

Post by edvinbesic »

e40 wrote: post #23
jawngee wrote: post #20

I swear I must be the only person in the world that has no problems using submodules and I use them constantly . It puzzles me that people have such problems with it, which I guess illustrates how unreliable anecdotal evidence really is. I've had detached head issues, but nothing that didn't take a minute or two to solve. It might be that I'm using SourceTree exclusively, so maybe SourceTree is hiding away the painfu…

which I guess illustrates how unreliable anecdotal evidence really is. Or, maybe your use case skirts around the problems?

I think you're both saying the same thing.

Re: Mastering Git submodules

#26

Post by bronson »

gitaarik wrote: post #6

I wrote very a brief how-to on Git Submodules [1] for my colleagues a while ago, because a lot of people seemed to have trouble with it. It explains the real basics and how to use them painlessly in most situations. So it's much shorter than the OP's article and that might help if you don't want to force everyone in your team to read a big article like this. [1]: https://gist.github.com/gitaarik/8735255

This guide seems woefully incomplete and optimistic. No coverage of submodule merge conflicts? No describing how to checkout a revision before the submodule was added or after it was removed, or how to bisect a project with submodules? No warnings about accidentally abandoning commits on submodules? (maybe: don't edit files in a submodule and for pity's sake never commit to one without immediately pushing?) Should also probably cover what your whole team must do when a submodule moves or gets renamed upstream.

Also, you might want to mention how git status is affected by submodules (& diff, log, etc).

Finally, I'm not sure you should make --init --recursive the default. If you don't realize a project contains submodules, you're going to make mistakes.

Re: Mastering Git submodules

#27

Post by bronson »

jawngee wrote: post #20

I swear I must be the only person in the world that has no problems using submodules and I use them constantly . It puzzles me that people have such problems with it, which I guess illustrates how unreliable anecdotal evidence really is. I've had detached head issues, but nothing that didn't take a minute or two to solve. It might be that I'm using SourceTree exclusively, so maybe SourceTree is hiding away the painfu…

I'd guess you aren't working on a team, and don't check out commits before your submodules were added?

If you don't roll forward and back in time (bisect), and you don't have merge conflicts, and you can easily resolve abandoned commits on submodules (i.e. you don't have to wait for Bangalore to wake up and push their changes) then, yes, you probably won't have many issues.

Re: Mastering Git submodules

#28

Post by jessaustin »

nawitus wrote: post #19
jessaustin wrote: post #3

Nice to see this caveat right at the beginning: On the other hand, if the technological context allows for packaging and formal dependency management, you should absolutely go this route instead: it lets you better split your codebase, avoid a number of side effects and pitfalls that litter the submodule space, and let you benefit from versioning schemes such as semantic versioning (semver) for your dependencies.

The drawback is that things like feature branches are more difficult to use. For example, with npm you need to resort to various scripts or handle them by yourself manually.

You're right, but in general I don't think any npm module ought to depend on a feature branch of another npm module. If a feature is worth keeping around, it's worth publishing (even if only to your private npm repo). If 19 different projects want 19 different behaviors from the module.foobar() function, then split the function up or pass it flag parameters or whatever, but don't keep 19 different versions of the code floating around. Pain is inevitable in that scenario. Of course while you're developing a new feature you might want to use it from another module on your dev machine, but "npm link" is what you want to use for that.

Re: Mastering Git submodules

#29

Post by rspeer »

kolev wrote: post #2

I use them daily and they're painful! Thankfully, there's Peru [0]. Unfortunately, it only works on Python 3.3+. [0] https://github.com/buildinspace/peru

What's unfortunate there? It's not like Python is hard to install.

Re: Mastering Git submodules

#30

Post by dukerutledge »

jawngee wrote: post #20

I swear I must be the only person in the world that has no problems using submodules and I use them constantly . It puzzles me that people have such problems with it, which I guess illustrates how unreliable anecdotal evidence really is. I've had detached head issues, but nothing that didn't take a minute or two to solve. It might be that I'm using SourceTree exclusively, so maybe SourceTree is hiding away the painfu…

If you are using submodules for pinning external resources to a specific hash then you probably won't have problems. If you are using them to manage multiple internal resources with varying levels of coupling...you will.
Post reply on HN