[PATCH 2 of 3] commit: add a -M/--reuse-message option to copy a commit message from a
Durham Goode
durham at fb.com
Sat May 16 20:24:55 CDT 2015
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.
Whether this option should be on rebase or not, I kind lean towards no
there.
More information about the Mercurial-devel
mailing list