Re: [PATCH 04/17] revert: Rename no_replay to record_origin

[Jonathan Nieder <jrnieder@gmail.com>]

Ramkumar Ramachandra wrote:

> Thanks for probing.  Found out the reason after some digging.
>
> revert: Rename no_replay to record_origin
>
> The "-x" command-line option is used to record the name of the
> original commits being picked in the commit message.  The variable
> corresponding to this option is named "no_replay" for historical
> reasons.

Heh.  I guess "for crazy historical reasons no one remembers, and it's
especially confusing because the term 'replay' is used to describe
from time to time to describe what cherry-pick does (e.g., in the
documentation for the --mainline option)" would be enough of a summary
to justify the change.

> This name was introduced in f810379 (Make builtin-revert.c
> use parse_options, 2007-10-07) to replace "replay", the opposite of
> "no_replay".  The name "replay" was introduced in 9509af6 (Make
> git-revert & git-cherry-pick a builtin, 2007-03-01).

It's actually older than that: it comes from the scripted version:

	-x|--i-really-want-to-expose-my-private-commit-object-name)
		replay=
		;;

>From v1.4.3-rc2~12 (cherry-pick: make -r the default, 2006-10-05;
it's of course older than that), we learn that this used to be the
default, disabled by a --replay option that meant

	Usually the command appends which commit was
	cherry-picked after the original commit message when
	making a commit.  This option, '--replay', causes it to
	use the original commit message intact.  This is useful
	when you are reordering the patches in your private tree
	before publishing.

or in other words, "simulate making the commit anew again, instead
of explicitly recording that this is a new commit based on that
old one".

In other words, "replay" originally essentially meant what
"cherry-pick" does now.

Thanks, that was interesting.

Cheers,
Jonathan