Here's an extremely common use case of histedit for me: 1. Write some code that belongs in a patch that's not the last patch I've committed (if it's the last patch, I'd just use amend). 2. Commit into a temporary commit. 3. Use histedit to fold the temporary commit into the commit it belongs to. In such cases, I invariably want to keep commmit message of the commit I'm folding into, and it's annoying to have the commit message editor open up with: <my real commit message> *** <my temporary commit message> and have to delete the latter two lines and save. It would be nice if there were an action in histedit which is like 'fold' but avoids this editing step and just keeps the first patch's commit message.
Setting priorities. The utility to complexity ratio here is probably too low for this feature to be accepted and is probably mooted by evolve anyway. Adding people who care about this stuff for a second opinion. You might want to investigate the evolve extension, which lets you amend anything and is the official roadmap for dealing with these sorts of workflow issues.
(In reply to comment #1) I do use the evolve extension! How do you "amend anything" with it?
1. Check out revision to amend 2. Make changes 3. Run "hg amend" But perhaps your issue is you did step two before step one and now have to do some shuffling.
(In reply to comment #3) Yeah - I don't want to have to check out the revision I'm amending into first. A common variant on the workflow I presented in comment 0 is: 1. Write some code, without particular regard as to which commit it should go into. 2. Do some "record"'s to sort the newly written code into chunks that should be amended into various commits, yielding several temporary commits. 3. Use histedit to fold the temporary commits into the respective commits where they belong. Again, I just want to re-use the commit messages of the existing commits without having to interact with an editor for each one. I don't think evolve's functionality addresses this use case.
For reference, the Git equivalent ('git rebase -i') has a 'fixup' action for this: it folds the commit into the previous commit and throws away the commit message. I found this action useful when I used it. In my experience, the fixup commits often appear out of sequence -- I spot a typo introduced in an earlier commit while working on another piece of code.
Maybe I ended my previous comment too early: I mention out-of-sequence commits with a dirty working copy becausethis means that you'll want to eventually reorder the commits when everything is committed. This makes 'hg histedit' the tool to use instead of the evolve-enabled 'hg amend'.
I would actually not mind seeing this if we can come up with a good name for the verb. It's struck me as one of the missing-ish features from rebase -i that I would use periodically. I also agree that evolution in its current form isn't really a substitute - histedit lets me do things much more gracefully after a prolonged period of hacking without committing (or making semi-arbitrary checkpoint commits). Anyone object if I reopen the bug? It should actually be a very easy task.
I would be happy to see this reopened.
Reopening as per comments 7 and 8.
*** Bug 4131 has been marked as a duplicate of this bug. ***
Fixed by http://selenic.com/repo/hg/rev/d2a5986cb89d Mike Edgar <adgar@google.com> histedit: add "roll" command to fold commit data and drop message (issue4256) This new histedit command (short for "rollup") is a variant of "fold" akin to "hg amend" for working copy: it accumulates changes without interrupting the user and asking for an updated commit message. (please test the fix)
I tested the fix; it seems to be working well. Thanks!
rock & roll
What release is this fix targeting - 3.2?
Yes, this should be present in 3.2, which should release tomorrow or as soon as feasible thereafter.
(In reply to comment #15) Ok, thanks. Out of curiosity, is there a way I could have found that out myself? (I'm used to bug trackers having a "Target Milestone" field that gives this information.)
http://mercurial.selenic.com/wiki/TimeBasedReleasePlan is the closest - we don't "target" a fix to a release - once a patch is in, it'll be in the next major release.