[RFC] Separating last-revision from parents

Aaron Bentley aaron.bentley at utoronto.ca
Fri Feb 2 03:49:12 GMT 2007

Hash: SHA1

Henry Ludemann wrote:
> Suggest pull when asked to merge into an empty branch.
> Merging to an empty tree fails (see bug 82555 for testcase and attempted
> fixes).

In that bug, Henry suggests separating last-revision and pending-merges
back to the way they used to be.

I've been thinking about a related issue lately, and I think separation
is good, but we should have last_revision, and pending_parents.

When we do an update, we swap the left and right parents, so that the
resulting revision is a merge of the local branch into the master
branch, not a merge of the master branch into the local branch.

But this make 'revert' a highly dangerous command, because it will throw
away all your local *committed* changes.

It also make status and diff behave strangely, because it changes the
basis of comparison.

And it also isn't so hot for doing multiple iterations of update,
resolve conflicts, update, which is probably the most desirable workflow
when you have two sync problems (tree out of date with local branch
*and* local branch out of date with master branch).

So one option would be a 'swap-parents' flag.  But that's rather
arbitrary.  If there's more than two parents, which one should become
the new last-revision?

Why not just say "parents" is about the parents of the revision that
will be created, and have a separate value for last-revision?

That would mean swapping parents wouldn't change the basis revision,
which would fix status, diff and revert.  Update would be a more
tractable problem, too.

Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the bazaar mailing list