hgattic feature request

[Bill Barry]

Hans Meine wrote:
> The situation I was talking about is
>
> (start with clean working dir)
> $ hg unshelve some_unfinished_experiment
> $ .. do work (did not work out/finish the experiment yet)
> $ hg shelve
>
>   
That should be shelving to your applied patch. If you list the attic 
contents right before shelving you should see that 
some_unfinished_experiment is in the applied state.

When working with attic there are 3 possible states that a patch can be in:

Nothing: patch is known about because it is in the attic directory, but 
it is not in use at all.

Current: patch represents the last patch you shelved or the patch you 
are currently working with, for providing a default name to unshelve 
with (note about the unshelve --reverse option here on the latest 
version, allowing you to remove the currently applied patch without 
getting rid of the other changes you may have; this is the big reason 
why the current patch is tracked even when applied)

Applied: patch is currently applied to your working directory, allowing 
you to shelve without specifying the name

$ hg unshelve mypatch
(mypatch is marked as the applied patch [also in current state, but that 
is irrelevant for everything except unshelve --reverse])
$ .. do work
$ hg shelve --refresh
(mypatch is updated in the attic, but remains applied)
$ .. do work
$ hg shelve
(should be shelving 'mypatch')
(mypatch is marked as current)
$ .. do work
$ hg shelve
(should either shelve default, or if it exists complain and do nothing)
>   
>>> Anyhow, a rename would be useful for other purposes, too.  A simple file
>>> mv is a) inconvenient, and b) may require editing
>>> .hg/attic/.{current,applied}.
>>>       
>> I agree it would be useful. It isn't currently there because I was
>> unsure where to place it:
>>
>> `hg shelve [-f | --force] --rename newname`
>> * would allow you to rename the applied patch
>> * -f option would allow overwrites
>>     
>
> I would never look at hg shelve for this.  After all - I do not want to put it 
> back into my attic, I just want to change the name.
>
>   
You could leave it applied with --refresh. The idea with this one is 
that you would necessarily be working with some patch in order to rename 
it, so you probably would have it applied. It also fits better with the 
analogy (take the box marked "toy cars" off the shelf, drop in an rc 
helicopter, relabel it as "rc toys" and put it back up).
>> `hg attic-rename [-f | --force] [name] newname`
>> * would allow you to rename [name] (which would default to
>> applied/current) to newname regardless of the current patch state
>> * -f option would allow overwrites
>>     
>
> That looks exactly like what I need.
>
>   
>> `hg attic-fold  [-f | --force] [-l | --leave] [name1] [name2] ...
>> [nameN] newname`
>> * for 0 optional patch names it would rename the current patch to newname
>> * for 1 named patch it would rename it
>> * for more than one named patch it would fold patches together
>> * -f would allow overwrites
>> * -l would leave the old patch(es) in place
>>     
>
> That would also do the trick, but it's a lot more complex than needed.
> I would prefer to still have attic-rename along with it.
>   
attic-rename is just a special case of attic-fold, fold also allows an 
easy to remember short form whereas rename would conflict with a core 
command:

$ hg shelve mypatch
$ hg fold newpatchname
(would rename mypatch to newpatchname, leaving this patch as the current 
one)

Note however that this extends to the intended future joining of attic 
to mq:
$ .. do work
$ hg shelve myqueue/
(would shelve to myqueue/myqueue1)
$ hg unshelve
(would mark myqueue as applied and unshelve patch1 from it)
$ hg attic-qpush
(would push the current changes into a temporary commit)
$ .. do work
$ hg attic-qpush secondpatch
(would push these changes into a commit and save the patch as well to 
.hg/attic/myqueue/secondpatch)
$ .. do work
$ hg shelve
(would shelve current unfinished changes as myqueue/myqueue2, remove 
temp commits and leave working dir clean; attic would contain 
myqueue/myqueue1, myqueue/secondpatch, myqueue/myqueue2, and 
myqueue/series with the patches in this order; .hg/attic/.applied would 
be empty; .hg/attic/.current would contain the string "myqueue/")
$ hg fold betternamedqueue/
(myqueue/ would be renamed betternamedqueue/, .current would be updated)
$ hg fold preexistingqueue/
(given that preexistingqueue/ also exists in attic, betternamedqueue/ 
would be appended to the end of it)
$ hg fold onebigpatch
(the queue comprising of all the patches in preexistingqueue/ would be 
folded into a single patch in attic)
$ hg fold betternameforpatch
(patch would be renamed)
>   
>> The current *proper* ways to rename a patch in the attic currently are:
>> 1: use unshelve --delete
>>     
>
> Ah, never used --delete so far.  Again, this is more or less what I would have 
> expected to be the default behaviour.  Think of my attic analogy again - when 
> I take something from the attic, it will not stay there, right?  Again, of 
> course your design requires to leave the patch in the attic, since it is sort 
> of a destructive action to "move" it into the working dir.
>   
You could always set --delete in your .hgrc

I must warn though that you would lose features from attic if you do this:
* patch is no longer under management of attic (no more .applied or 
.current patch if you delete it)
* lose the patch header (commit text, user, date)

I suspect you aren't using the patch headers based on how you have said 
you are doing this, so you will not really notice that missing.
>   
>> $ hg unshelve --delete oldpatchname
>> $ hg shelve newpatchname
>>     
>
> Nice, I will use that as a workaround for now I think.
>
>   
>>> BTW: Last time I rm/mv'ed the current patch w/o editing the above files,
>>> hgattic choked, i.e. threw exceptions.
>>>       
>> Oops, thought that was fixed.
>>     
>
> Note that I have not checked with the latest version before writing that 
> comment, just some feedback which came to my mind.
>
> We should maybe 
>   
You should use the newest version. It merges patches forwards instead of 
just attempting to apply them (and possibly getting rejects). While this 
takes a little longer, it is much nicer than winding up with a random 
failed patch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20091209/78415084/attachment.html>