Re: Git Vs. Svn for a project which *must* distribute binaries too.
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jun 5, 2007, 02:56 UTC
- Message-ID
- <Pine.LNX.4.64.0706050345250.4046@racer.site>
- In-Reply-To
- <20070604212121.GA31852@dspnet.fr.eu.org>
Hi,
On Mon, 4 Jun 2007, Olivier Galibert wrote:
Show 13 quoted lines
> 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