Re: Git Vs. Svn for a project which *must* distribute binaries too.

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, 4 Jun 2007, Thomas Glanzmann wrote:
> 
> >  - 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