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

Hi,

On Mon, 4 Jun 2007, Olivier Galibert wrote:

On Mon, Jun 04, 2007 at 01:45:26PM -0700, Linus Torvalds wrote:

quoted

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