Fix committer name ?

Stephen J. Turnbull stephen at
Tue May 26 07:08:29 BST 2009

Andrew Cowie writes:

 > On Mon, 2009-05-25 at 12:48 +0200, Xavier MAILLARD wrote:
 > > I need to read about rebase.
 > [as I understand it:]
 > Rebasing creates new [completely new] revisions with content similar to
 > the set it is replacing.

This is correct, except that the content is *identical*.  So if Xavier
merges his rebased branch with the old head *immediately*, he should
get zero conflicts.  I wonder if this might not be a solution for

1. create a copy branch
2. rebase the original
3. merge *from* the copy into the (rebased) original
4. have downstream merge as usual

IIUC (this is hard though), downstream should get exactly the same
merge conflicts as if they had bzr merge'd from Xavier's updated
(original) branch.  Their history will be a bit ugly, of course,
because in the history up to their "cleanup" merge they'll have the
incorrect metadata.

Perhaps they need to

1. clone Xavier's new (rebased and merged) branch
2. merge from their old branch into the new clone
3. clean up merge conflicts

 > So long as **no one else** has the old revisions, you can continue your
 > work from this point, discarding your old work.
 > If **anyone else** has the original revisions and in turn builds upon
 > them, then there is nothing you can do.

This is not true.  There are a bunch of recipes out there (including
in the git-rebase manpage, IIRC) for "cleaning up" when upstream has
rebased behind your back.

It *is* an imposition on downstream, though, and should be negotiated
with them.  In the extreme case where all of your downstream just
passively pull from you, you just have them clone your branch again;
it's not a big deal.  If most of them have one branch off your branch,
again, it's not that hard, they just rebase their branch.

 > All you are doing is creating a second set of revisions with
 > exactly the same thing as the originals, and it will likely cause
 > merge conflicts when your "new" revisions are later merged with
 > your original ones.

Possible, but not guaranteed.

 > I *DO* wish we had a way to commit changes to metadata; then we could
 > clean up these things.

Git has a (obscurely documented) "grafts" file, which contains pairs
of commits which git should consider to be equivalent for the purpose
of tracing parentage.  I'm not sure what it's used for in git, but
maybe something like that would be feasible in Bazaar for this purpose.

More information about the bazaar mailing list