RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:
There are plans to use git-subtree in RHEL-7 kernel source tree and although
it's already supported on the current git version for RHEL-7 a feature that was
enabled in version 1.9.0 (negative pathspec ':!<path>') will be required. Its
usage was already proposed and posted for RHEL-8 and there the developers are
requiring at least git 2.13 in order to perform the desired task due to some
improvements on negative pathspec.

Because of that I would like to require an update to git 2.13 on RHEL-7 as
well, thus we can maintain the same code base as RHEL-8 for the desired
feature. In case it's not possible due to some dependency issue an update to at
least 1.9.0 would be enough.

Version-Release number of selected component (if applicable):
git version 1.8.3.1

How reproducible:
one of the commands that will be performed is:
$ git format-patch --no-renames -k --stdout ${lasttag}.. -- ':!redhat' | <awk-script>

which is used to generate kernel srpm changelog.

Actual results:
fatal: Unimplemented pathspec magic '!' in ':!/redhat'

Expected results:
no output

Additional info:
Please, focus on updating to 2.13. Just in case it's not
possible, update to 1.9.0 or newer.

Hello, can you use rh-git218 from RHSCL? https://access.redhat.com/errata/RHEA-2018:3554 https://access.redhat.com/documentation/en-us/red_hat_software_collections/3/html/3.2_release_notes/chap-rhscl#sect-RHSCL-Changes-git

(In reply to Pavel Cahyna from comment #2)
> Hello, can you use rh-git218 from RHSCL?
> https://access.redhat.com/errata/RHEA-2018:3554
> https://access.redhat.com/documentation/en-us/red_hat_software_collections/3/
> html/3.2_release_notes/chap-rhscl#sect-RHSCL-Changes-git

Well, for myself it would be enough, but the change will require every kernel developer within RedHat to also use rhscl git package.
I'm not sure if require them all to take this step would be better than a base tools update. What do you think?

What is the problem with using the rhscl git package, is it the need of doing "scl enable ..." before using git?

(In reply to Pavel Cahyna from comment #4)
> What is the problem with using the rhscl git package, is it the need of
> doing "scl enable ..." before using git?

Actually that's not a problem. TBH I never really used scl in my daily work, hence I'm not sure what are the requirements to require an update on base tools when newer versions are present on scl.
Maybe with more people requiring such new version would be a good idea to update (at least to 1.9.0)? If that's not feasible or not recommended that's ok by me.

The conclusion so far is that we should not update the package and let the users who need a newer version use SCL, that's why we provide it.