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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html