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

11–20 of 33 posts

Re: Mastering Git submodules

#11

Post by chocolateboy »

perlgeek wrote: post #8
chocolateboy wrote: post #5

For a less painful [1] solution, see git-subrepo. [2] [1] https://github.com/ingydotnet/git-subrepo/blob/master/Intro.... [2] https://github.com/ingydotnet/git-subrepo

I use git-subrepo too, but it has its own sets of warts. It generates pretty verbose (and ugly) commit messages made of json. It doesn't let you do anything (like a pull or clone) when you working directory is dirty. But on the whole, it is often less painful than submodules. I haven't tried subtree yet, will do that next :-)

> It generates pretty verbose (and ugly) commit messages made of json.

This was fixed recently. [1]

> I haven't tried subtree yet, will do that next :-)

The git-subrepo intro has a pretty good overview of the issues with git-subtree. [2]

[1] https://github.com/ingydotnet/git-subrepo/issues/40

[2] https://github.com/ingydotnet/git-subrepo/blob/master/Intro....

Re: Mastering Git submodules

#12

Post by perlgeek »

chocolateboy wrote: post #11
perlgeek wrote: post #8

Earlier quoted context omitted.

I use git-subrepo too, but it has its own sets of warts. It generates pretty verbose (and ugly) commit messages made of json. It doesn't let you do anything (like a pull or clone) when you working directory is dirty. But on the whole, it is often less painful than submodules. I haven't tried subtree yet, will do that next :-)

> It generates pretty verbose (and ugly) commit messages made of json. This was fixed recently. [1] > I haven't tried subtree yet, will do that next :-) The git-subrepo intro has a pretty good overview of the issues with git-subtree. [2] [1] https://github.com/ingydotnet/git-subrepo/issues/40 [2] https://github.com/ingydotnet/git-subrepo/blob/master/Intro....

OK, the commit messages are less ugly now, but they still give the wrong kind of information.

Four lines of the commit message are about git-subrepo, which I don't care about. I'm not a git-subrepo developer, and don't care what version of the tool was used to generate the commit.

What I do care a lot about is why a commit was made, and those auto-generated commit messages don't tell me that at all. They can't, because the tools don't read minds. That's why git usually prompts me for a commit message. I like that. It's one of the reasons I'm using version control. It would be nice if git-subrepo played along.

Re: Mastering Git submodules

#13

Post by chocolateboy »

perlgeek wrote: post #12
chocolateboy wrote: post #11

Earlier quoted context omitted.

> It generates pretty verbose (and ugly) commit messages made of json. This was fixed recently. [1] > I haven't tried subtree yet, will do that next :-) The git-subrepo intro has a pretty good overview of the issues with git-subtree. [2] [1] https://github.com/ingydotnet/git-subrepo/issues/40 [2] https://github.com/ingydotnet/git-subrepo/blob/master/Intro....

OK, the commit messages are less ugly now, but they still give the wrong kind of information. Four lines of the commit message are about git-subrepo, which I don't care about. I'm not a git-subrepo developer, and don't care what version of the tool was used to generate the commit. What I do care a lot about is why a commit was made, and those auto-generated commit messages don't tell me that at all. They can't, becau…

The metadata in the commit message isn't used in any way, so you can always:

  git commit --amend
I personally find it a useful default, though, i.e. there's not usually much more I want to say than "added a subrepo: [metadata...]", and, for something like this, I'd rather err on the side of too much information than too little.

Re: Mastering Git submodules

#14

Post by Navarr »

> 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 installed to multiple top-level project directories. It is a nightmare (and is better served by the composer efforts for dependency management).

Re: Mastering Git submodules

#15

Post by donatj »

We used them for a few months and it was always painful. Always. We ended up writing our own composer installer plugin that let us put things in the various places we need them and it's been soo much better. Someone needs to make a dead simple non language specific git-tag package manager where I just specify github.com/blah:1.0.* -> folder/blah and it keeps it up to date. It's what we're using composer for but its a stretch.

Re: Mastering Git submodules

#16

Post by ern »

TheHippo wrote: post #7

I find git subtrees[1] way better then submodules. [1]: http://blogs.atlassian.com/2013/05/alternatives-to-git-submo... P.S.: Since when is GoDoc a dependency manager for Go?

Agreed.

It should be noted that there are two confusingly similar concepts in the git - the subtree merge strategy and the git subtree command (which is, in fact a git command like git submodule, a point which seems ambiguous in the OP).

Re: Mastering Git submodules

#17

Post by ericclemmons »

tinco wrote: post #10

At work we have a git repository called the 'projectname/super-project'. Developers clone this repo, and all it contains is a pair of shell scripts and a bunch of git modules. A module for every project, it's a SaaS cluster, we have projects like 'http-frontend', 'http-backend', 'gateway', 'indexer', 'marketing-website' and some forks of open source projects we customized for our use case. After a fresh developer has…

Nice to see this post! We're dismantling a monolith and choose this exact same solution. I'm glad it's working out in the wild.

Re: Mastering Git submodules

#19

Post by nawitus »

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.

Re: Mastering Git submodules

#20

Post by jawngee »

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 painful bits or something.

Post reply on HN