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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Mon, 4 Jun 2007, Olivier Galibert wrote:

> On Mon, Jun 04, 2007 at 01:45:26PM -0700, Linus Torvalds wrote:
>
> > 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)
> 
> Wouldn't it be possible to register the rebase somewhere (weak parent? 
> some kind of note not influencing the sha1 ?) that pull/merge could 
> follow?

Actually, with reflogs (if you did not explicitely disable them), you 
should have the information already.

> Rebases and cherry-picking are a special kind of merge, so maybe it can 
> be handled like one where it counts...

There is something I have to add as a real disadvantage in rebase:

Usually you are expected to test your commits. So, say that you work on 
some patch series, and produce 3 well tested patches. Then you fetch 
upstream and realize it advanced by some commits, and rebase your three 
patches.

However, _none_ of your patches is well tested, because there is a quite 
real chance that your patches interact _badly_ with the patches you just 
fetched.

And if that is the case, git-bisect can very well attribute it to a wrong 
patch, either because more than one patch is bad, or because the last 
patch in your series _exposes_ the bug (but does not _introduce_ it).

Ciao,
Dscho