monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: Undo a commit


From: Thomas Keller
Subject: Re: [Monotone-devel] Re: Undo a commit
Date: Fri, 10 Oct 2008 11:46:48 +0200
User-agent: Thunderbird 2.0.0.17 (X11/20080922)

Ludovic Brenta schrieb:
> Selon Daniel Carrera <address@hidden>:
>> Daniel Carrera wrote:
>>> So I am clear, the entire command is "mtn db_kill_rev_locally" and 
>>> that's it? If we convinced the devs to make "mtn uncommit" an alias to
> 
>>> "mtn db_kill_rev_locally" would that cover my use case?
>> I just tried this on a sandbox branch and it doesn't work that well. In
>>
>> particular, it fails if there are any uncommitted changes:
>>
>> % mtn status
>> Current branch: foo.sandbox.branch
>> Changes against parent dcfbf59823cf21e292b60ba8f8463f65ea383597
>>    added    foo
>>
>> % mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597
>> mtn: misuse:
>> Cannot kill revision dcfbf59823cf21e292b60ba8f8463f65ea383597, because
>>
>> it would leave the current workspace in an invalid state, from which 
>> monotone cannot recover automatically since the workspace contains 
>> uncommitted changes. Consider updating your workspace to another 
>> revision first, before you try to kill this revision again.
>>
>>
>>
>> This is not good. Suppose I have edited files Foo1, Foo2 and Bar. I run
>>
>> "mtn commit Foo1" because I forgot about Foo2. So I decide I want to 
>> undo that last commit so I can run "mtn commit Foo1 Foo2" which is what
>>
>> I wanted initially. Monotone won't let me do it because file Bar has 
>> changes.
> 
> That's where my trick comes in: manually edit _MTN/revision without
> changing anything else in your workspace, then kill the head revision.

I'd do it "safely" without messing around with _MTN/revision and move
the current changes aside to re-apply them later on:

$ mtn diff > current_changes.txt
$ mtn revert .
$ mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597
$ patch -p0 < current_changes.txt

Of course we could teack kill_rev_locally also to accept workspace
changes and essentially do a workspace merge for these cases, but I'm
not sure if there is really a use case for this which is worth to mess
with that.

What kill_rev_locally is really useful for right now is...

$ mtn ci foo bar/baz
[enter log message]
[revision committed]
"oh fuck, I forgot one file!", "oh fuck, I forgot to describe a change!"
$ mtn db kill_rev_locally <rev>
$ mtn ci foo bar/baz bla
...

In my opinion, for all other use cases people should actually work with
 disapprove + merge, since this also allows to redo changes when there
already exist children to the bad revision.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]