Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-55284

Command line git tag collision behavior changed in git 2.20

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: git-client-plugin
    • Labels:
      None
    • Environment:
      Git client plugin 2.7.4 and earlier
    • Similar Issues:

      Description

      The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) and the stable-2.7 branch are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

      Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

      Git 2.20.0 release notes explain the change as:

      "git push" into refs/tags/* hierarchy is rejected without getting forced, but "git fetch" (misguidedly) used the "fast forwarding" rule used for the refs/heads/* hierarchy; this has been corrected, which means some fetches of tags that did not fail with older version of Git will fail without "--force" with this version.

      The git client plugin seems to have been relying on the misguided fast forward rule.

      The man page for git 2.20 recommends strongly against moving (re-tagging) a tag on a shared repository. It says:

      However, Git does not (and it should not) change tags behind users back. So if somebody already got the old tag, doing a git pull on your tree shouldn’t just make them overwrite the old one.

      If somebody got a release tag from you, you cannot just change the tag for them by updating your own one. This is a big security issue, in that people MUST be able to trust their tag-names. If you really want to do the insane thing, you need to just fess up to it, and tell people that you messed up.

      The test_fetch_with_updated_tag results report:

      hudson.plugins.git.GitException: 
      Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
      stdout: 
      stderr: 
       * branch            HEAD       -> FETCH_HEAD
       ! [rejected]        t          -> t  (would clobber existing tag)
      

      That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

      This affects git client plugin 2.7.4 and git client plugin 3.0.0. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.

        Attachments

          Issue Links

            Activity

            markewaite Mark Waite created issue -
            markewaite Mark Waite made changes -
            Field Original Value New Value
            Description The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            Needs more analysis to decide how best to handle the new behavior.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.
            The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            Needs more analysis to decide how best to handle the new behavior.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0 unit tests. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.
            markewaite Mark Waite made changes -
            Description The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            Needs more analysis to decide how best to handle the new behavior.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0 unit tests. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.
            The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            Needs more analysis to decide how best to handle the new behavior.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0 unit tests. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.

            This isn't a Java 11 compatibility issue really, but it was discovered because the Java 11 docker image uses a Debian release that provides command line git 2.20.1. The choice by the Java 11 docker image to use Debian sid is quite surprising to me, since "Sid is unstable" and is not intended to be used for production. However, that's an issue for the Java 11 docker image, not for the git client plugin.
            markewaite Mark Waite made changes -
            Labels java11-compatibility
            markewaite Mark Waite made changes -
            Environment Git client plugin 3.0.0-beta6 Git client plugin 2.7.4 and earlier
            markewaite Mark Waite made changes -
            Description The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            Needs more analysis to decide how best to handle the new behavior.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0 unit tests. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.

            This isn't a Java 11 compatibility issue really, but it was discovered because the Java 11 docker image uses a Debian release that provides command line git 2.20.1. The choice by the Java 11 docker image to use Debian sid is quite surprising to me, since "Sid is unstable" and is not intended to be used for production. However, that's an issue for the Java 11 docker image, not for the git client plugin.
            The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) and the stable-2.7 branch are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            Needs more analysis to decide how best to handle the new behavior.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0 unit tests. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.

            This isn't a Java 11 compatibility issue really, but it was discovered because the Java 11 docker image uses a Debian release that provides command line git 2.20.1. The choice by the Java 11 docker image to use Debian sid is quite surprising to me, since "Sid is unstable" and is not intended to be used for production. However, that's an issue for the Java 11 docker image, not for the git client plugin.
            markewaite Mark Waite made changes -
            Description The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) and the stable-2.7 branch are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            Needs more analysis to decide how best to handle the new behavior.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0 unit tests. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.

            This isn't a Java 11 compatibility issue really, but it was discovered because the Java 11 docker image uses a Debian release that provides command line git 2.20.1. The choice by the Java 11 docker image to use Debian sid is quite surprising to me, since "Sid is unstable" and is not intended to be used for production. However, that's an issue for the Java 11 docker image, not for the git client plugin.
            The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) and the stable-2.7 branch are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            Needs more analysis to decide how best to handle the new behavior. [Git 2.20.0 release notes|https://github.com/git/git/blob/b21ebb671bb7dea8d342225f0d66c41f4e54d5ca/Documentation/RelNotes/2.20.0.txt#L11] explain the change as:

            {quote}
            "git push" into refs/tags/* hierarchy is rejected without getting forced, but "git fetch" (misguidedly) used the "fast forwarding" rule used for the refs/heads/* hierarchy; this has been corrected, which means some fetches of tags that did not fail with older version of Git will fail without "--force" with this version.
            {quote}

            The git client plugin test seems to have been relying on the misguided fast forward rule. Can confirm that by checking that the test is not performing a fast forward change from the old tag to the new tag.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0 unit tests. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.

            This isn't a Java 11 compatibility issue really, but it was discovered because the Java 11 docker image uses a Debian release that provides command line git 2.20.1. The choice by the Java 11 docker image to use Debian sid is quite surprising to me, since "Sid is unstable" and is not intended to be used for production. However, that's an issue for the Java 11 docker image, not for the git client plugin.
            markewaite Mark Waite made changes -
            Description The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) and the stable-2.7 branch are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            Needs more analysis to decide how best to handle the new behavior. [Git 2.20.0 release notes|https://github.com/git/git/blob/b21ebb671bb7dea8d342225f0d66c41f4e54d5ca/Documentation/RelNotes/2.20.0.txt#L11] explain the change as:

            {quote}
            "git push" into refs/tags/* hierarchy is rejected without getting forced, but "git fetch" (misguidedly) used the "fast forwarding" rule used for the refs/heads/* hierarchy; this has been corrected, which means some fetches of tags that did not fail with older version of Git will fail without "--force" with this version.
            {quote}

            The git client plugin test seems to have been relying on the misguided fast forward rule. Can confirm that by checking that the test is not performing a fast forward change from the old tag to the new tag.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0 unit tests. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.

            This isn't a Java 11 compatibility issue really, but it was discovered because the Java 11 docker image uses a Debian release that provides command line git 2.20.1. The choice by the Java 11 docker image to use Debian sid is quite surprising to me, since "Sid is unstable" and is not intended to be used for production. However, that's an issue for the Java 11 docker image, not for the git client plugin.
            The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) and the stable-2.7 branch are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            [Git 2.20.0 release notes|https://github.com/git/git/blob/b21ebb671bb7dea8d342225f0d66c41f4e54d5ca/Documentation/RelNotes/2.20.0.txt#L11] explain the change as:

            {quote}
            "git push" into refs/tags/* hierarchy is rejected without getting forced, but "git fetch" (misguidedly) used the "fast forwarding" rule used for the refs/heads/* hierarchy; this has been corrected, which means some fetches of tags that did not fail with older version of Git will fail without "--force" with this version.
            {quote}

            The git client plugin test seems to have been relying on the misguided fast forward rule. Can confirm that by checking that the test is not performing a fast forward change from the old tag to the new tag.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0 unit tests. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.

            This isn't a Java 11 compatibility issue really, but it was discovered because the Java 11 docker image uses a Debian release that provides command line git 2.20.1. The choice by the Java 11 docker image to use Debian sid is quite surprising to me, since "Sid is unstable" and is not intended to be used for production. However, that's an issue for the Java 11 docker image, not for the git client plugin.
            markewaite Mark Waite made changes -
            Labels java11-compatibility
            markewaite Mark Waite made changes -
            Description The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) and the stable-2.7 branch are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            [Git 2.20.0 release notes|https://github.com/git/git/blob/b21ebb671bb7dea8d342225f0d66c41f4e54d5ca/Documentation/RelNotes/2.20.0.txt#L11] explain the change as:

            {quote}
            "git push" into refs/tags/* hierarchy is rejected without getting forced, but "git fetch" (misguidedly) used the "fast forwarding" rule used for the refs/heads/* hierarchy; this has been corrected, which means some fetches of tags that did not fail with older version of Git will fail without "--force" with this version.
            {quote}

            The git client plugin test seems to have been relying on the misguided fast forward rule. Can confirm that by checking that the test is not performing a fast forward change from the old tag to the new tag.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0 unit tests. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.

            This isn't a Java 11 compatibility issue really, but it was discovered because the Java 11 docker image uses a Debian release that provides command line git 2.20.1. The choice by the Java 11 docker image to use Debian sid is quite surprising to me, since "Sid is unstable" and is not intended to be used for production. However, that's an issue for the Java 11 docker image, not for the git client plugin.
            The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) and the stable-2.7 branch are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            [Git 2.20.0 release notes|https://github.com/git/git/blob/b21ebb671bb7dea8d342225f0d66c41f4e54d5ca/Documentation/RelNotes/2.20.0.txt#L11] explain the change as:

            {quote}
            "git push" into refs/tags/* hierarchy is rejected without getting forced, but "git fetch" (misguidedly) used the "fast forwarding" rule used for the refs/heads/* hierarchy; this has been corrected, which means some fetches of tags that did not fail with older version of Git will fail without "--force" with this version.
            {quote}

            The git client plugin test seems to have been relying on the misguided fast forward rule. Can confirm that by checking that the test is not performing a fast forward change from the old tag to the new tag.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0 unit tests. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.
            markewaite Mark Waite made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            markewaite Mark Waite made changes -
            Remote Link This issue links to "PR-386 (Web Link)" [ 22116 ]
            markewaite Mark Waite made changes -
            Description The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) and the stable-2.7 branch are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            [Git 2.20.0 release notes|https://github.com/git/git/blob/b21ebb671bb7dea8d342225f0d66c41f4e54d5ca/Documentation/RelNotes/2.20.0.txt#L11] explain the change as:

            {quote}
            "git push" into refs/tags/* hierarchy is rejected without getting forced, but "git fetch" (misguidedly) used the "fast forwarding" rule used for the refs/heads/* hierarchy; this has been corrected, which means some fetches of tags that did not fail with older version of Git will fail without "--force" with this version.
            {quote}

            The git client plugin test seems to have been relying on the misguided fast forward rule. Can confirm that by checking that the test is not performing a fast forward change from the old tag to the new tag.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0 unit tests. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.
            The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) and the stable-2.7 branch are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            [Git 2.20.0 release notes|https://github.com/git/git/blob/b21ebb671bb7dea8d342225f0d66c41f4e54d5ca/Documentation/RelNotes/2.20.0.txt#L11] explain the change as:

            {quote}
            "git push" into refs/tags/* hierarchy is rejected without getting forced, but "git fetch" (misguidedly) used the "fast forwarding" rule used for the refs/heads/* hierarchy; this has been corrected, which means some fetches of tags that did not fail with older version of Git will fail without "--force" with this version.
            {quote}

            The git client plugin seems to have been relying on the misguided fast forward rule.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0 unit tests. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.
            markewaite Mark Waite made changes -
            Description The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) and the stable-2.7 branch are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            [Git 2.20.0 release notes|https://github.com/git/git/blob/b21ebb671bb7dea8d342225f0d66c41f4e54d5ca/Documentation/RelNotes/2.20.0.txt#L11] explain the change as:

            {quote}
            "git push" into refs/tags/* hierarchy is rejected without getting forced, but "git fetch" (misguidedly) used the "fast forwarding" rule used for the refs/heads/* hierarchy; this has been corrected, which means some fetches of tags that did not fail with older version of Git will fail without "--force" with this version.
            {quote}

            The git client plugin seems to have been relying on the misguided fast forward rule.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0 unit tests. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.
            The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) and the stable-2.7 branch are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            [Git 2.20.0 release notes|https://github.com/git/git/blob/b21ebb671bb7dea8d342225f0d66c41f4e54d5ca/Documentation/RelNotes/2.20.0.txt#L11] explain the change as:

            {quote}
            "git push" into refs/tags/* hierarchy is rejected without getting forced, but "git fetch" (misguidedly) used the "fast forwarding" rule used for the refs/heads/* hierarchy; this has been corrected, which means some fetches of tags that did not fail with older version of Git will fail without "--force" with this version.
            {quote}

            The git client plugin seems to have been relying on the misguided fast forward rule.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.
            markewaite Mark Waite made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            markewaite Mark Waite made changes -
            Status In Review [ 10005 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            markewaite Mark Waite made changes -
            Summary Command line git tag collision behavior changed in git 2.20.1 Command line git tag collision behavior changed in git 2.20
            markewaite Mark Waite made changes -
            Status Resolved [ 5 ] Closed [ 6 ]
            markewaite Mark Waite made changes -
            Description The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) and the stable-2.7 branch are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            [Git 2.20.0 release notes|https://github.com/git/git/blob/b21ebb671bb7dea8d342225f0d66c41f4e54d5ca/Documentation/RelNotes/2.20.0.txt#L11] explain the change as:

            {quote}
            "git push" into refs/tags/* hierarchy is rejected without getting forced, but "git fetch" (misguidedly) used the "fast forwarding" rule used for the refs/heads/* hierarchy; this has been corrected, which means some fetches of tags that did not fail with older version of Git will fail without "--force" with this version.
            {quote}

            The git client plugin seems to have been relying on the misguided fast forward rule.

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.
            The unit tests on the git client plugin master branch (git client plugin 3.0.0 targeted release) and the stable-2.7 branch are showing a repeatable failure in the CliGitAPIImplTest.test_fetch_with_updated_tag when run with command line git 2.20.1.

            Git for Windows now delivers command line git 2.20.1 as does Debian Unstable ("sid"). Other vendors are likely to include git 2.20.1 as well.

            [Git 2.20.0 release notes|https://github.com/git/git/blob/b21ebb671bb7dea8d342225f0d66c41f4e54d5ca/Documentation/RelNotes/2.20.0.txt#L11] explain the change as:

            {quote}
            "git push" into refs/tags/* hierarchy is rejected without getting forced, but "git fetch" (misguidedly) used the "fast forwarding" rule used for the refs/heads/* hierarchy; this has been corrected, which means some fetches of tags that did not fail with older version of Git will fail without "--force" with this version.
            {quote}

            The git client plugin seems to have been relying on the misguided fast forward rule.

            The [man page|https://git-scm.com/docs/git-tag#_on_re_tagging] for git 2.20 recommends *strongly* against moving (re-tagging) a tag on a shared repository. It says:

            {quote}However, Git does *not* (and it should not) change tags behind users back. So if somebody already got the old tag, doing a git pull on your tree shouldn’t just make them overwrite the old one.

            If somebody got a release tag from you, you cannot just change the tag for them by updating your own one. This is a big security issue, in that people MUST be able to trust their tag-names. If you really want to do the insane thing, you need to just fess up to it, and tell people that you messed up. {quote}

            The test_fetch_with_updated_tag results report:

            {noformat}
            hudson.plugins.git.GitException:
            Command "git fetch -t /tmp/jkh1542368834541434789" returned status code 1:
            stdout:
            stderr:
             * branch HEAD -> FETCH_HEAD
             ! [rejected] t -> t (would clobber existing tag)
            {noformat}

            That test is trying to fetch a tag from the remote when the remote has updated the tag to point to a different SHA1.

            This affects git client plugin 2.7.4 and git client plugin 3.0.0. Not yet clear which Jenkins use cases are harmed, only that there is a behavior change in command line git that the git client plugin automated tests have detected.
            markewaite Mark Waite made changes -
            Resolution Fixed [ 1 ]
            Status Closed [ 6 ] Reopened [ 4 ]
            markewaite Mark Waite made changes -
            Status Reopened [ 4 ] Fixed but Unreleased [ 10203 ]
            Resolution Fixed [ 1 ]
            markewaite Mark Waite made changes -
            Status Fixed but Unreleased [ 10203 ] Closed [ 6 ]

              People

              • Assignee:
                markewaite Mark Waite
                Reporter:
                markewaite Mark Waite
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: