Live data from Hacker News

Git Subtree merged into mainline git

github.com

11–20 of 39 posts

Re: Git Subtree merged into mainline git

#11
post #8

Earlier quoted context omitted.

> 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?

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!

Re: Git Subtree merged into mainline git

#12

Earlier quoted context omitted.

> 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 loc…

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.

Re: Git Subtree merged into mainline git

#13
post #8

Earlier quoted context omitted.

> 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?

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.
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.

Re: Git Subtree merged into mainline git

#14
post #7

I've never used git in-the-large, which may be why I don't understand: Why must some other library/module be part of my project? Why not reference and maintain the external lib/mod externally? We've been doing that for decades. It seems a solved problem. Bringing an external library within the fold of your project feels like unnecessary coupling.

One example would be:

  * https://github.com/altercation/solarized

  * https://github.com/altercation/vim-colors-solarized
The vim-colors-solarized repo is a subtree of the solarized repo. This is mostly a convenience for vim users that use something like pathogen + git-submodule to keep their plugins up-to-date. This way you can create a submodule @ ~/.vim/bundle/vim-colors-solarized and it would be the root of the bundle tree. If the vim colorscheme was only part of the larger repo, then users would be forced to create their own repos, or else do something like:

  git submodule .vim/bundle/.vim-colors-solarized
  ln -s .vim-colors-solarized/vim-colors-solarized .vim/bundle/

Re: Git Subtree merged into mainline git

#17
post #7

I've never used git in-the-large, which may be why I don't understand: Why must some other library/module be part of my project? Why not reference and maintain the external lib/mod externally? We've been doing that for decades. It seems a solved problem. Bringing an external library within the fold of your project feels like unnecessary coupling.

For instance because you have componentized your product into different repositories, use different combinations of the components in different projects, but are still actively developing many of them simultaneously on each of those projects. Having to build, deploy and fetch gems (or whatever other method of distribution your language uses) is cumbersome if development is still really active.

I don't think you should ever want to bring unreliable external components, like a random github project that you aren't actively contributing to, into your tree like that.

Re: Git Subtree merged into mainline git

#18
post #8

Earlier quoted context omitted.

> 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?

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.

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.

Re: Git Subtree merged into mainline git

#19

Earlier quoted context omitted.

> 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 loc…

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).

Re: Git Subtree merged into mainline git

#20
So this looks pretty awesome. I can see myself using it a lot. There is one workflow that I do with submodules, that i don't see how to do in subtrees:

clone a repo to the target dir. Add it as a submodule. Decide to play with a branch of the submodule, so switch to that branch in the cloned repo. Then if i decide to work with that, update my submodules, otherwise switch back.

Is that sort of workflow available in subtrees? How do I do it?

Post reply on HN