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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
