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? Rebases and cherry-picking are a special kind of merge, so > maybe it can be handled like one where it counts... Well, it's not like duplicate history is a disaster from a *technical* angle. It might be a small space-waster etc, but that's really not the real issue. The problem with duplicate history is that it just makes things much harder to look at. IOW, it's *messy*. So the "tons of confusion" part is basically purely about humans, not about git itself. Git won't really care, and there's no reason to "handle" it specially in that sense. So I would strongly discourage people from ever making rebased history available, but that's not because of any particular git technical issues as just because of it being a good way to confuse all the _humans_ involved. (That said, gits own 'pu' branch ends up jumping around, and it hasn't caused all that much confusion, so maybe I'm overstating even that human confusion) Linus - 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
