On 3/13/16 8:53 AM, Eli Zaretskii wrote:
>> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
>> Date: Sat, 12 Mar 2016 17:33:16 -0500
>> Cc: emacs-devel@gnu.org
>>
>> Personally, I think that handling cherry-picking and rebasing is
>> very secondary.
> 
> We use the former for backporting changes from master.

Cherry-picking a replaced commit works, as long as you use the
replacement SHA. This is the hash that shows up when you `git log`, so
it should just work without any thought on the part of the cherry-picker.

> As for the latter, I think quite a few people who track the
> development and contribute patches do that, so I think it's important
> for their workflows to be undisturbed.

I don't see why people who are tracking Emacs are rebasing commits which
have been pushed to the master or branch. Nonetheless, if you rebase and
one of the commits you are rebasing has been replaced, the replacement
gets used instead of the original.

In both of these cases, the new commit doesn't generate new replacement
commits. This means, for the use case we are thinking of here, that the
old (presumably incorrect) log message will be lost when you rebase or
cherry-pick.

-David


Here's my test log if you want to recreate my results, or poke around a
.git repo with replacements:

  mkdir -p /tmp/test/a
  cd /tmp/test/a
  git init
  echo a > a
  git add a
  git commit -m "a"
  echo b > a
  git add a
  git commit -m "changes"
  git replace --edit HEAD # changed the message in emacs to "b"
  git log # verified message was changed
  git checkout HEAD^
  git checkout -b c
  echo c > c
  git add c
  git commit -m "c"
  git log master
  git cherry-pick e3291a2f81bad7b24ba18e28e60378667ff78acd # The hash
that the previous `git log master` showed
  git log # verified cherry-picked commit has correct message
  find .git/refs/ # no new replacement refs created
  git checkout master
  git rebase c
  git log
  find .git/refs/ # no new replacement refs created