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 ]
            Hide
            markewaite Mark Waite added a comment -

            Fixed in git client plugin 2.7.5 released December 22, 2018

            Show
            markewaite Mark Waite added a comment - Fixed in git client plugin 2.7.5 released December 22, 2018
            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 ]
            Hide
            casey1911 Stanislav Jursky added a comment -

            Jenkins builds with Git client plugin 2.7.5 are still failing if there is tag update with same name.
            Still no --force parameter is used during tag fetch operation
             

            Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress git@host.com:group/repo.git +refs/heads/*:refs/remotes/origin/*" returned status code 1:
            ...
            ! [rejected]              same-tag     -> same-tag  (would clobber existing tag)

            And there is no "force tag" config in git plugin either.
             

            Show
            casey1911 Stanislav Jursky added a comment - Jenkins builds with Git client plugin 2.7.5 are still failing if there is tag update with same name. Still no  --force parameter is used during tag fetch operation   Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress git@host.com:group/repo.git +refs/heads/*:refs/remotes/origin/*" returned status code 1: ... ! [rejected] same-tag -> same-tag (would clobber existing tag) And there is no "force tag" config in git plugin either.  
            Hide
            henriklundahl Henrik Lundahl added a comment -

            Mark Waite, this is still a problem, as Stanislav Jursky wrote above. Can we re-open this?

            Show
            henriklundahl Henrik Lundahl added a comment - Mark Waite , this is still a problem, as Stanislav Jursky wrote above. Can we re-open this?
            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.
            Hide
            markewaite Mark Waite added a comment - - edited

            Shame on me! I fixed the unit test which discovered the problem but failed to test the problem in a real world use case. I've created a real world use case and confirmed that it fails in that use case.

            Sorry about the incomplete fix in git client plugin 2.7.5.

            Please be sure to review the git tag man page which explains why moving tags is strongly discouraged.

            Show
            markewaite Mark Waite added a comment - - edited Shame on me! I fixed the unit test which discovered the problem but failed to test the problem in a real world use case. I've created a real world use case and confirmed that it fails in that use case. Sorry about the incomplete fix in git client plugin 2.7.5. Please be sure to review the git tag man page which explains why moving tags is strongly discouraged.
            markewaite Mark Waite made changes -
            Resolution Fixed [ 1 ]
            Status Closed [ 6 ] Reopened [ 4 ]
            Hide
            markewaite Mark Waite added a comment -

            Henrik Lundahl and Stanislav Jursky could you test the build of the pull request I've submitted? I wrote a test that failed then made a code change to pass the test.

            Show
            markewaite Mark Waite added a comment - Henrik Lundahl and Stanislav Jursky could you test the build of the pull request I've submitted? I wrote a test that failed then made a code change to pass the test.
            Hide
            casey1911 Stanislav Jursky added a comment -

            Mark Waite, tested on Jenkins 2.157 . Build you refereed now works. Thanks.

            09:22:07  > git fetch --tags --force --progress git@host.com:group/repo.git +refs/heads/*:refs/remotes/origin/*
            

            Regarding moving tags. we want to move some of them intentionally. Yes there are tags for every build that we need to trust and not move. But some our special tags refers to actual deployed version in different environments. And there's a tooling around it. No user push/move them by their own. Kind of special repository. 

            Thanks for fix. 

            Going to test this one on old Jenkins 1.651.1   

            Show
            casey1911 Stanislav Jursky added a comment - Mark Waite , tested on Jenkins  2.157  . Build you refereed now works. Thanks. 09:22:07 > git fetch --tags --force --progress git@host.com:group/repo.git +refs/heads/*:refs/remotes/origin/* Regarding moving tags. we want to move some of them intentionally. Yes there are tags for every build that we need to trust and not move. But some our special tags refers to actual deployed version in different environments. And there's a tooling around it. No user push/move them by their own. Kind of special repository.  Thanks for fix.  Going to test this one on old Jenkins  1.651.1    
            Hide
            markewaite Mark Waite added a comment - - edited

            Fixed (in both places this time) in git client plugin 2.7.6 released January 10, 2019.

            Show
            markewaite Mark Waite added a comment - - edited Fixed (in both places this time) in git client plugin 2.7.6 released January 10, 2019.
            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: