Re: Git Vs. Svn for a project which *must* distribute binaries too.
- From
Linus Torvalds <torvalds@linux-foundation.org>
- Date
- Jun 4, 2007, 20:45 UTC
- Message-ID
- <alpine.LFD.0.98.0706041336440.23741@woody.linux-foundation.org>
- In-Reply-To
- <20070604175751.GL19935@cip.informatik.uni-erlangen.de>
On Mon, 4 Jun 2007, Thomas Glanzmann wrote:
Show 14 quoted lines
> > > - instead of doing a "git pull" that merges the two branches (your work, > > and the work that happened by somebody else in the central repo while > > you did it), you *may* also just want to do a "git fetch" to fetch the > > changes from the central repo, and then do "git rebase origin" to > > linearize the work you did on _top_ of those central repo one (so that > > it no longer looks like a branch, and looks linear) > > > > In the "git rebase" case, you'll effectively merge your commits one at > > a time, and you may thus have to fix up *multiple* conflicts. So it's > > potentially more work, but it results in a simpler history if you want > > it. > > Thank you a lot. I finally understood what "git rebase" is all about!
I'd like to point out some more upsides and downsides of "git rebase".
Downsides:
- you're rewriting history, so you MUST NOT have made your pre-rebase changes available publicly anywhere else (or you are in a world of pain with duplicate history and tons of confusion)
- you can only rebase "simple" commits. If you don't just have a linear history of your own commits, but have merged from others, rebasing isn't a sane alternative (yeah, we could make it do something half-way sane, but really, it's not worth even contemplating)
Upsides:
- while there may be more conflicts you have to sort out, they may be individually simpler, so you *might* actually prefer to do it that way.
- if the reason for the conflicts is that upstream did some nice cleanup in the same area, and you decide that you would actually want to re-do your development based on that nice cleanup, then "git rebase" can actually be used as a way to help you do exactly that. IOW, you can take _advantage_ of the conflicts as a way to re-apply the patches but also then fix them up by hand to work in the new (better) world order.
And finally, the upside that is probably the most common case for using "git rebase", and has nothing to do with resolving conflicts before pushing them out with "git push":
- if you actually want to send your changes upstream as emailed *patches* rather than by pushing them out (or asking somebody else to pull them), rebasing is an excellent way to keep the set of patches "fresh" on top of the current development tree.
People who send their patches out as emails are also unlikely to have the downsides (ie they normally send them as patches exactly *because* they don't want to make their git trees public, and they probably just have a small set of simple patches in their tree anyway)
So I have to say, I'm still very ambivalent about rebasing. It's definitely a very useful thing to do, but at the same time I think "git pull" in many ways is often the more honest and correct way to do things.
Linus