[PATCH v2] fast-import: avoid making replace refs point to themselves

From: Elijah Newren <newren@gmail.com>

If someone replaces a commit with a modified version, then builds on that commit, and then later decides to rewrite history in a format like

    git fast-export --all | CMD_TO_TWEAK_THE_STREAM | git fast-import

and CMD_TO_TWEAK_THE_STREAM undoes the modifications that the replacement did, then at the end you'd get a replace ref that points to itself. For example:

    $ git show-ref | grep replace
    fb92ebc654641b310e7d0360d0a5a49316fd7264 refs/replace/fb92ebc654641b310e7d0360d0a5a49316fd7264

Git commands which pay attention to replace refs will die with an error when a self-referencing replace ref is present:

    $ git log
    fatal: replace depth too high for object fb92ebc654641b310e7d0360d0a5a49316fd7264

Avoid such problems by deleting replace refs that will simply end up pointing to themselves at the end of our writing. Unless users specify --quiet, warn them when we delete such a replace ref.

Two notes about this patch:
  * We are not ignoring the problematic update of the replace ref
    (turning it into a no-op), we are replacing the update with a delete.
    The logic here is that if the repository had a value for the replace
    ref before fast-import was run, and the replace ref was explicitly
    named in the fast-import stream, we don't want the replace ref to be
    left with a pre-fast-import value.
  * While loops with more than one element (e.g. refs/replace/A points
    to B, and refs/replace/B points to A) are possible, they seem much
    less plausible.  It is pretty easy to create a sequence of
    git-filter-repo commands that will trigger a self-referencing replace
    ref, but I do not know how to trigger a scenario with a cycle length
    greater than 1.

Signed-off-by: Elijah Newren <newren@gmail.com>
---
    fast-import: avoid making replace refs point to themselves
    
    Changes since v1: Clarified wording in the commit message, and added a
    little more text at the end of the commit message to address questions
    that came up in review.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1824%2Fnewren%2Ffast-import-self-pointing-replace-ref-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1824/newren/fast-import-self-pointing-replace-ref-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/1824

Range-diff vs v1:

 1:  7402518e806 ! 1:  cc77a004cea fast-import: avoid making replace refs point to themselves
     @@ Commit message
              $ git show-ref | grep replace
              fb92ebc654641b310e7d0360d0a5a49316fd7264 refs/replace/fb92ebc654641b310e7d0360d0a5a49316fd7264
      
     -    Most git commands that you try to run in such a repository with a
     -    self-pointing replace object will result in an error:
     +    Git commands which pay attention to replace refs will die with an error
     +    when a self-referencing replace ref is present:
      
              $ git log
              fatal: replace depth too high for object fb92ebc654641b310e7d0360d0a5a49316fd7264
      
          Avoid such problems by deleting replace refs that will simply end up
     -    pointing to themselves at the end of our writing.  Warn the users when
     -    we do so, unless they specify --quiet.
     +    pointing to themselves at the end of our writing.  Unless users specify
     +    --quiet, warn them when we delete such a replace ref.
     +
     +    Two notes about this patch:
     +      * We are not ignoring the problematic update of the replace ref
     +        (turning it into a no-op), we are replacing the update with a delete.
     +        The logic here is that if the repository had a value for the replace
     +        ref before fast-import was run, and the replace ref was explicitly
     +        named in the fast-import stream, we don't want the replace ref to be
     +        left with a pre-fast-import value.
     +      * While loops with more than one element (e.g. refs/replace/A points
     +        to B, and refs/replace/B points to A) are possible, they seem much
     +        less plausible.  It is pretty easy to create a sequence of
     +        git-filter-repo commands that will trigger a self-referencing replace
     +        ref, but I do not know how to trigger a scenario with a cycle length
     +        greater than 1.
      
          Signed-off-by: Elijah Newren <newren@gmail.com>
      

 builtin/fast-import.c  | 16 +++++++++++++++-
 t/t9300-fast-import.sh | 28 ++++++++++++++++++++++++++++
 2 files changed, 43 insertions(+), 1 deletion(-)