Git Subtree merged into mainline git
github.com
Git Subtree merged into mainline git
1–10 of 39 posts
Re: Git Subtree merged into mainline git
#2If you want to know what the git subtree command is, see http://apenwarr.ca/log/?m=200904#30
Re: Git Subtree merged into mainline git
#3Subtree > 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.
Re: Git Subtree merged into mainline git
#4If you want to know what the git subtree command is, see http://apenwarr.ca/log/?m=200904#30
Way more useful than the linked article. Many thanks.
Re: Git Subtree merged into mainline git
#5Subtree > 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…
> 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?
Re: Git Subtree merged into mainline git
#6Subtree > 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…
> 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!
Re: Git Subtree merged into mainline git
#7I'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.
Re: Git Subtree merged into mainline git
#8Subtree > 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…
> 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.
Re: Git Subtree merged into mainline git
#9I'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.
Dependency control it is a solved problem. Which is why SVN has externals, Hg has hgsubs, and Git has submodules and now subtrees. This isn't a git-in-the-large problem, it's an almost-any-nontrivial-project problem. It only seems unnecessary 'till you've had it and tried to live without it.
Bringing other libraries into my project is beneficial because then my build system is able to wrangle those just as easily as my code. (And it's also simply useful in the case where I've written both modules but maintain a separation for whatever reason--one is an open-source project and the other is not, whatever--to be able to make changes to one from within the other, run the tests for the submodule, and push it up to staging or upstream, without having to leave my current project.)
Re: Git Subtree merged into mainline git
#10I'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.
Yes exactly.
After you have divided your project into independent modules you have agreed that the changes in these modules are going to have minimal impact on each other, then what exactly is the point of merging the history of all those changes?.In my use case that would actually create a bigger mess.
Now I think this could perhaps be useful if there are modules that I have forked from elsewhere and the fork is going to be used in my project only.Although even then I dont see any downside of using submodules.
The downside of submodules is lack of good commands .For example a command to check out a different branch of each of my submodules - the branch which is used in this project.This could be done using the -for-each tag but its not trivial.
EDIT:In this thread zbowling makes a great argument against submodules.
There is a horrible habit of people forking projects on github just so their submodule stay stable