[RFC] uncommit and pull --overwrite emit merge directives?

John Arbash Meinel john at arbash-meinel.com
Wed Aug 15 16:36:31 BST 2007

Hash: SHA1

Marius Kruger wrote:
> On 8/15/07, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
>> Alternatively, we could hide the directives in the branch directory, and
>> provide pull --undo and uncommit --undo.
> that will be very sweet!!
> will that literary undo the pull or uncommit?

I'm a little concerned that it wouldn't be quite what people expect. But
it should be possible. Basically, all you really need is a single
revision id marker that people can pull back to. Whether we want to
present that as 2 commands (pull --undo, uncommit --undo) and thus 2
associated revision ids.

It certainly can be done as a merge directive, though a single revision
id is even simpler.

My concern with uncommit, is that if you commit, change things a little
bit, uncommit, and then uncommit --undo, it may actually conflict with
the things you changed. uncommit deals solely with the Branch pointer,
the only changes to the working tree are tracking the pending merges. (I
suppose this is a reason to have uncommit --undo, since it can handle
those points).

So my personal preference would be for uncommit and pull to just set a
"this was the revision id before I did the command". Which can be stored
in the .bzr/{branch/checkout/temp?} metadata.

I think "bzr revert" is a stronger case for having a real merge
directive, because it removes uncommitted changes. (And possibly pull,
since it does update the WT.)

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


More information about the bazaar mailing list