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

Augie Fackler raf at durin42.com
Sun May 17 20:07:53 CDT 2015


> On May 16, 2015, at 21:24, Durham Goode <durham at fb.com> wrote:
> 
> We've had this conversation IRL, but putting my response here as well for the communities viewing pleasure.
> 
> On 5/16/15 12:06 AM, Pierre-Yves David 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).
> If you felt this was useful two years ago, there's probably a ton of people who feel it's useful now and haven't had the two years to learn ways around it.  I think it's a useful command, and it's worth catering towards many different workflows.
> 
> Also, we're a long way from everyone having access to evolve, so I don't think we should block useful features based on it.
>> 
>> 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.
> "hg commit -m "$(hg log -r X -T '{desc}')"" is a pretty poor user experience (not to mention it requires knowledge of bash, log, and templates), and I don't think we should require that users set up aliases to get a good experience.
>> 
>> 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.
> Sure, UI bloat is bad, but I don't think we should block legitimately useful features because we're worried about an extra line in the help text.  Commit currently has 16 options.  I think we're pretty far from it becoming unreadable.

Fair point. Given how ugly the bashism to replace this is, I think I'm coming around, but with no short flag.

> Whether this option should be on rebase or not, I kind lean towards no there.

I didn't even read far enough into the patch to catch that. I think this flag makes sense only on commit - import and backout also seem silly (unless you've got a use case, which I'm open to hearing, I just can't imagine one offhand...)


> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel



More information about the Mercurial-devel mailing list