Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:43:14
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? 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