Comment by zbowling | Hacker News Reader

Comment by zbowling | Hacker News Reader

Subtree > Submodule in so many ways. Git submodule is a mess and now a legacy of git.

I've been been using subtree in a fork of Git personally but can't (safely) use it at work with everyone else (still use submodules there).

This is going to be a problem for github for reasons I put in my blog a few months back: http://zbowling.github.com/blog/2011/11/25/github/

Because Github has their explicit, top down, a-fork-is-only-a-fork-by-clicking-the-fork-button kind of graph between projects, using subtree won't work easily with their online tools to do pull-requests and see the network graph of forks.

Basically my repo is going to have the histories of 7 different projects combined in one repo and from that single repo I will be pushing back changes to all 7 (and others versions of those 7). Github's pull request feature is going to have trouble with that concept because they make the invalid assumption of a single upstream.

There are work arounds for sure like pushing your changes to a staging repo before finally doing a pull-request upstream but that is cumbersome. I'll probably write a shell script to automate it.

> Git submodule is a mess and now a legacy of git.

I hear this kind of thing all the time, but I don't understand why. I've never had any problem whatsoever with git submodule. Can you elaborate a bit on what you mean by this?

Off the top of my head:

Ever tried removing a submodule? Why is there no git submodule rm? (No, "it's confusing" is not a valid argument.)

If the pull fails (say, from the wrong protocol), you end up with a half-baked submodule. Impossible to move, impossible to remove, impossible to update unless you dive into the config.

Misspell the folder you wanted the submodule in? That sucks. Go delete it from two separate locations, and try again!

Yes these problems suck.

Sometimes I have deleted my entire repository and cloned it again to update the submodules just because I changed the .gitmodules file.

Note: This actually takes less commands than messing around with .git/config.

If that is the worst problem -- one that is easy to solve and easy to repeat the few times you need it -- then the more love for submodules. I'll take that over any other available solution any day (I don't count subtrees as 'available' yet).

Speaking of git submodule rm, here's a basic script I use for that [1], based on Stackoverflow's answer [2].

1. https://github.com/byrongibson/scripts/blob/master/git-rm-su...

2. http://stackoverflow.com/questions/1260748/how-do-i-remove-a...

Ever had an upstream gitsubmodule move or shut down? I can't go back 6 months in my SCM and rebuild exactly what I had because the repo is gone now. This is bad and against the concept of having an SCM in the first place.

There is a horrible habit of people forking projects on github just so their submodule stay stable. It's broken.

>There is a horrible habit of people forking projects on github just so their submodule stay stable. It's broken.

Yes I do this and I hate doing it!

  > There is a horrible habit of people forking
  > projects on github just so their submodule
  > stay stable. It's broken.

People are forking projects on github in that way because it's a quick, easy, cheap way to create a mirror/hosted copy of the repository they want to use.

I don't see how this is an example of how git-submodule is broken. If you want to use someone else's code, that is under someone else's control in your repository without creating your own backup of said code, then you're the one taking the risk by not creating said backup.

If the git-submodule is mission-critical to you then you should either:

1. Always keep a separate mirror of the 3rd party repo.

or

2. Mirror the 3rd party repo to a hosted location, so that your submodule can point to the mirror instead of the source (basically creating a caching layer under your control).

This is no different than the guy that keeps all of his email in Gmail, then complains because Google shut down his account that 'email is broken' because it's possible for this to happen.

Sure. Why I explained the work around. Subtree includes the full history of the other project without work-arounds

subtree also includes the full history of the other project in your project's history unless you squash all of the commits (and if you squash them, then you haven't stored the full history). There might also be licensing reasons for wanting to keep the repositories separate, but not.

Which is why you should only use submodules with repositories under your control. At my work we happily use git submodules. Much better than svn externals and much better than any alternative that existed so far.

Reply on news.ycombinator.com