There are so many flags that can be passed to git, it seems impossible for the git plugin to keep up.

      For example, see JENKINS-21248 which asks to get shallow clone support for submodules (e.g., passing --depth 1 for submodule inits). Who knows when this ticket is going to be addressed?

      If we just had a text area where we could input custom flags to the git command, we could bypass this need for the plugin to represent every flag in git with a checkbox.

          [JENKINS-23860] allow for custom flags to be passed to git

          Mark Waite added a comment -

          I think the request is infeasible, unless we provide a "command line arguments" field for every git command we invoke, in every context where it is invoked.

          For example, the current git commands used by the plugin include:

          • --version
          • branch
          • checkout
          • clone
          • config
          • describe
          • fetch
          • init
          • log
          • merge
          • notes
          • rev-parse
          • submodule add
          • submodule init
          • submodule sync
          • tag

          Those commands are used in specific contexts, with some used in multiple contexts. I don't see how we could represent a user interface to the user which would describe the location of the usage, without fully describing the details of that usage so that they knew the context. The user interface to allow command line control of each of those contexts is much more work and much more difficult to explain to users than the current, simplified model.

          Mark Waite added a comment - I think the request is infeasible, unless we provide a "command line arguments" field for every git command we invoke, in every context where it is invoked. For example, the current git commands used by the plugin include: --version branch checkout clone config describe fetch init log merge notes rev-parse submodule add submodule init submodule sync tag Those commands are used in specific contexts, with some used in multiple contexts. I don't see how we could represent a user interface to the user which would describe the location of the usage, without fully describing the details of that usage so that they knew the context. The user interface to allow command line control of each of those contexts is much more work and much more difficult to explain to users than the current, simplified model.

          Aaron Simmons added a comment -

          Providing a "command line arguments" field for every command would work.

          Otherwise the plugin is going to fall further and further behind git's features. If this ticket is wontfix, and tickets like JENKINS-21248 are rejected, what are end users supposed to do?

          Aaron Simmons added a comment - Providing a "command line arguments" field for every command would work. Otherwise the plugin is going to fall further and further behind git's features. If this ticket is wontfix, and tickets like JENKINS-21248 are rejected, what are end users supposed to do?

          Mark Waite added a comment -

          JENKINS-21248 was not rejected as an enhancement request, it was rejected because the author of the enhancement refused to implement it so that the enhancement would be maintainable in future versions. That is the submitter's right, as part of an open source project, but it is also the maintainer's right to reject changes which make the plugin more difficult to maintain.

          The git plugin and the git client plugin are installed in over 30000 Jenkins installations. We're trying to be very careful that changes accepted into the git client plugin and the git plugin will not break those 30000+ installations and will be maintainable and extensible for future versions.

          The tight coupling which would be created between a "command line arguments" field for every git command in the git client plugin and the UI would make the implementation even more tightly attached to the command line git implementation. The JGit implementation (also in the git client plugin) would be unable to adapt to those command line arguments, as would any future alternate implementations (like a libgit2 based implementation).

          If you'd like to join the efforts to improve the git-client-plugin, you're encouraged to join the development community and submit "pull requests". I'd love to see your proposals, and particularly in submodules we could use many more unit tests to confirm the plugin is behaving as expected.

          Mark Waite added a comment - JENKINS-21248 was not rejected as an enhancement request, it was rejected because the author of the enhancement refused to implement it so that the enhancement would be maintainable in future versions. That is the submitter's right, as part of an open source project, but it is also the maintainer's right to reject changes which make the plugin more difficult to maintain. The git plugin and the git client plugin are installed in over 30000 Jenkins installations. We're trying to be very careful that changes accepted into the git client plugin and the git plugin will not break those 30000+ installations and will be maintainable and extensible for future versions. The tight coupling which would be created between a "command line arguments" field for every git command in the git client plugin and the UI would make the implementation even more tightly attached to the command line git implementation. The JGit implementation (also in the git client plugin) would be unable to adapt to those command line arguments, as would any future alternate implementations (like a libgit2 based implementation). If you'd like to join the efforts to improve the git-client-plugin, you're encouraged to join the development community and submit "pull requests". I'd love to see your proposals, and particularly in submodules we could use many more unit tests to confirm the plugin is behaving as expected.

            ndeloof Nicolas De Loof
            paleozogt Aaron Simmons
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: