Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#45895 - [git] contains two copies of

Attached to Project: Arch Linux
Opened by Jack O'Connor (oconnor663) - Tuesday, 04 August 2015, 14:00 GMT
Last edited by Toolybird (Toolybird) - Friday, 02 June 2023, 06:29 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Dan McGee (toofishes)
Christian Hesse (eworm)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


The packaging script makes a copy of the script, and both the original and the copy make it into the final package. Their contents are identical.

> sha1sum /usr/share/git/**/
2c5de0abe4106f5f6a778e568491f0f761e99af0 /usr/share/git/completion/
2c5de0abe4106f5f6a778e568491f0f761e99af0 /usr/share/git/
This task depends upon

Closed by  Toolybird (Toolybird)
Friday, 02 June 2023, 06:29 GMT
Reason for closing:  Won't fix
Additional comments about closing:  See comments
Comment by Eli Schwartz (eschwartz) - Thursday, 03 August 2017, 17:18 GMT
We do this for a lot of contrib stuff, actually, as after the PKGBUILD copies or `make install`s various things from contrib/ it finishes off by archiving the whole contrib/ as /usr/share/git/
Comment by Christian Hesse (eworm) - Friday, 04 August 2017, 09:52 GMT
I think we should keep it that way... Any reason to do?
Comment by Eli Schwartz (eschwartz) - Friday, 04 August 2017, 11:47 GMT
Minimal saving of space on things that aren't strictly necessary on an installed system? I dunno, but I have been going on a rampage recently trying to resolve longstanding bugtracker tickets so I'd like to see some decision specifically made. :p
Comment by Jack O'Connor (oconnor663) - Friday, 04 August 2017, 14:25 GMT
I certainly don't feel strongly about this one, but it seems a bit...untidy? Maybe more practically, it's hard to know which path is the more stable one that I should depend on, when I'm writing long-term configs and helper scripts. Presumably we don't want to commit to having both paths for the long term? Though if we do want that, then all the more power to us :)
Comment by Johannes Altmanninger (krobelus) - Sunday, 19 April 2020, 11:24 GMT
One possible reason to keep the "contrib/" in the directory structure:

The git frontend "tig" expects to find the "diff-highlight" script in /usr{,/local}/share/git{,-core}/contrib/diff-highlight

In Arch, this "diff-highlight" is in /usr/share/git/diff-highlight/
For the record, in Debian "tig" doesn't find this script either because it is installed in /usr/share/doc/git/contrib/diff-highlight/

Granted, "diff-highlight" is in contrib and not installed by "make install", so "tig" seems to be ill-advised in choosing those paths in the first place.
Hence we probably shouldn't change it.
Comment by Toolybird (Toolybird) - Friday, 02 June 2023, 06:29 GMT
This is old and stale...and seems like a very minor issue not worth worrying about. See PM's comments above.