[PATCH 2 of 3] commit: add a -M/--reuse-message option to copy a commit message from a

[Durham Goode]

On 5/16/15 5:43 PM, Augie Fackler wrote:
> On May 16, 2015, at 3:06 AM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
>
>>
>> On 05/15/2015 03:54 PM, Tony Tung wrote:
>>> # HG changeset patch
>>> # User Tony Tung <tonytung at fb.com>
>>> # Date 1429655274 25200
>>> #      Tue Apr 21 15:27:54 2015 -0700
>>> # Node ID dc122dd80665762d8febe2db1a08ce00a63d5ab8
>>> # Parent  18cadf9d058931ef00e5272d15cb5cf2ebc3a248
>>> commit: add a -M/--reuse-message option to copy a commit message from a
>>> revspec
>>>
>>> One way to split up a diff that includes a refactor involves resetting to
>>> the ancestor, and then committing the refactor first.  When committing the
>>> main change, it's helpful to be able to reuse the commit message from the
>>> earlier commit that includes both the refactor and the new functionality.
>>> This makes it easy to grab the commit message.
>> My personal opinion is that we do not need this feature as an explicit commit flag. There is multiple reason for that.
>>
>> 1) about two years ago, while using mercurial, I felt the need for such flag, but it eventually faded. Nowaday I really barely use it. I believe my need faded away because of two commands from evolve: "hg fold" the removed my need to use "revert+commit" to fold things together. And "hg uncommit" who removed my need to use "revert+commit" to redo a commit. (you can replace "revert+commit" with "strip -k+commit" too).
>>
>> 2) achieving the same feature is already quite easy thanks to the shell. power. one can achieve the same result using `hg commit -m "$(hg log -r X -T '{desc}')"`. When I used this on a regular basis, I setup a 'desc' command alias and I was about to get -M using: hg ci -m `hg desc X` something concise enough for the frequency I needed it.
>>
>> 3) We have to be careful of UI bloat and any option added to commit trickle down to a lot of the other command. The amount of different help changed in this patch is a good sign of that. The fact we added it on rebase, because of the --collapse feature that is already mostly foreign to rebase is also a good sign of that.
>>
>>
>> To conclude. given that (1) we can provide better option for the same effect, (2) there is already option to get this done today with "reasonable" cost (3) commit is a very critical command regarding UI bloat. I do not think the Utility/bloat ratio is good enough for this new flag.
> I’m inclined to agree with marmoute on this one, I’m afraid. This just isn’t something I see done enough to justify the ui complexity (and spending one of our precious short flags on.)
I see users ask for this on a regular basis.  Their needs usually fall 
into a few categories:

- They screwed up a commit and their solution is to undo the commit and 
redo it. They want to use the same commit message as before.
- They want to split a commit up.  They enter into histedit, choose 
'edit', but when they go to make the first commit, they can't reuse the 
commit message from the original commit.
- They have a stack of experimental commits and want to redo the stack 
correctly before sending it out. They want to reuse some of the commit 
messages from the old stack.
- They accidentally screwed up their commit message. (hg amend -m 
usually).  They recover a commit from a bundle and want to amend that 
commit message into their current commit.

Heck, I myself have needed it twice in the last few days (and resorted 
to bash-isms to work around it), but I need it pretty much every time I 
work with complex stacks for hg-crew (usually for point #3 above).  
Every item I list above has workarounds, but we can't possibly teach all 
our users the "right" way to do things, so supporting what they find to 
be the intuitive solution (i need a commit message, so let me copy it 
from somewhere) is worth it in my opinion.

I'm fine if we drop the short flag though.