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

Matt Mackall mpm at selenic.com
Sun May 17 20:57:13 CDT 2015


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.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial-devel mailing list