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

Durham Goode durham at fb.com
Mon May 18 12:53:58 CDT 2015



On 5/17/15 6:57 PM, Matt Mackall wrote:
> On Fri, 2015-05-15 at 15:54 -0700, 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.
> For future reference, "resetting" is git-speak that I don't understand,
> despite having looked at the git-reset manpage countless times. Please
> don't make me learn git to understand your commit messages, because git
> makes me sad. Please instead use "updating to", "reverting to", or
> whatever version of --hard/--soft/--bouncy you mean corresponds to.
>
> I vaguely recall discussing this option with Ryan, perhaps at the
> sprint. I understand the value of the feature, but I think it's below
> the threshold for UI clutter.
>
> One way of getting around that is to make a more generically useful
> feature with lower UI footprint. For instance, log historically has a
> ton of individual options to specify which revisons to show:
> --keyword/date/follow/follow-first/only-branch/only-merges/no-merges/limit/user/prune, etc.
>
> We were far past the point where things were cumbersome, the
> combinations didn't make sense, and it still wasn't expressive enough
> for all the things users wanted, and new things only worked for log.
>
> Now compare that with revsets: basically everything supports revsets,
> they're vastly more powerful and expressive, and adding new features to
> revsets doesn't clutter the help and implementation of every command.
>
> So a more "generic" version of this feature might look like this:
>
>   hg commit -u @255 -m @255 -d @255  # copy the metadata from cset 255
>
> ..but would have further reaching consequences:
>
>   hg log -d @.  # show commits with the same date as the current one
>
>   hg log -r "files(@bookmark)" # show commits that touch the same files
>
> The per-command implementation would look something like:
>
>    if opts["message"]:
>       message = cmdutil.expandopt(repo, "description", opts["message"])
>
> There are a bunch of problems with the precise form of the above,
> starting with the fact that we obviously already use "@" for other
> things, but I think it illustrates why a generic approach is more
> valuable and maintainable.
>
I like the idea of a generic solution.  What about 'hg commit -m 
{255}'?  Templates use {} to indicate "replace this with the desired 
value", so we could do the same in commands and revsets, where appropriate.

Would you be ok if it was only done for commit -m initially?  That seems 
like the 95% case.


More information about the Mercurial-devel mailing list