Fixing rebase rather than avoiding it (was: Dulwich on Launchpad)

[Jelmer Vernooij]

On Wed, 2010-03-03 at 13:19 -0500, Stefan Monnier wrote:
> >> Yes, I occasionally rebase after the fact. This is mainly caused by my
> >> personal setup.
> > Yet another reason to avoid rebase :-)
> 
> I disagree.  I'd say it's another reason why we should fix rebase (and
> support it right instead).
> 
> Rebase should not destroy history: it should only alter history by
> adding more arcs (and nodes) into the DAG, basically providing an
> alternate history.  I understand that adding a parent is not something
> that Bzr supports right now, but that doesn't change anything to the
> fact that it would be the right thing to do.
Bazaar (like Git or Mercurial) doesn't support modifying history; this
includes adding parents. 

OTOH It could add the original revision as one of the parents to the
newly created revisions as part of the rebase, but I'm not sure of how
much value this is - it seems like it would just cause disk usage to go
through the roof and confuse the hell out of users because their history
would include a lot of (seemingly) duplicate revisions. The whole point
of rebase (as I understand it from Git users) is to clean up history and
get rid of those old commits.

bzr-rebase already sets a 'rebase-of' revision property that contains
the revision id of the revision the newly created revision is a rebase
of. 

Please also note that while "bzr dpush" has similar behaviour to rebase
in that it appears to rewrite existing revisions, this is done for
different reasons - the revisions are rewritten to exclude anything that
can not be represented in the target vcs.

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20100303/3116dc83/attachment.pgp