Re: Git Vs. Svn for a project which *must* distribute binaries too.
- From
Linus Torvalds <torvalds@linux-foundation.org>
- Date
- Jun 4, 2007, 21:33 UTC
- Message-ID
- <alpine.LFD.0.98.0706041429380.23741@woody.linux-foundation.org>
- In-Reply-To
- <20070604212121.GA31852@dspnet.fr.eu.org>
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? 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