Arch Linux User Repository

@liljayli I was the one that filed an orphan request for this. I missed adopting it by a few hours. Deep down in the comment history you can see I have some involvement is sorting out conflicts as well. Would you mind if I join you as a co-maintainer?

Patch for latest version:

diff --git a/PKGBUILD b/PKGBUILD
index b0b462a..ebdd0f1 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -4,7 +4,7 @@
 # All my PKGBUILDs are managed at https://github.com/eli-schwartz/pkgbuilds

 pkgname=git-extras
-pkgver=6.2.0
+pkgver=6.3.0
 pkgrel=1
 pkgdesc="GIT utilities -- repo summary, commit counting, repl, changelog population and more"
 arch=('any')
@@ -12,8 +12,8 @@ url="https://github.com/tj/${pkgname}"
 license=('MIT')
 depends=('git')
 source=("${pkgname}-${pkgver}.tar.gz::${url}/archive/${pkgver}.tar.gz")
-sha256sums=('151bc129f717179c1f7b6c83faf1d4829eeddef8b7c501dac05dc38c28270c3e')
-b2sums=('71e3be3f56ca049d2060c79b8dd52aacf613d9157fc5d6fa76c827b59e9355f16903cce94e09dcf73e0c7c4f81b422a37234dbc8f9eb146ca9925da8778ea2dc')
+sha256sums=('8a218a0c8e10036d5ba14f26b70f994b0d11166b02ef3fed71c593cef026ec3d')
+b2sums=('263e192015e46da7867f131c19ae47243e60355cba02b1860b45abafdc4fc6adf916dffce58b853960d8bb22f5da067e1dca6ed0b02f108953571896d1c981c4')

 package() {
     cd "${srcdir}/${pkgname}-${pkgver}"

The upstream Makefile doesn't deploy it either, because there's not exactly a defined place for such a thing. I'm not inventing some undocumented file location which no one knows about, myself, and I'm not going to spam users who don't care about zsh in order to tell them how to work around the failure to use zsh's completion system.

If I added it to the docdir, I'm definitely not going to add an install script mentioning it.

However, installing it as documentation seems like a reasonable compromise to make, so I guess I'm willing to retract my previous protests against "inventing some undocumented file location". It will be up to users to discover it for themselves...

@eschwartz: If nothing else, they could be installed to /usr/share/doc/git-extras/completions/ so a user can copy them from there.

Upstream added fish completions which are not installed, to go with existing zsh completions which are not installed.

There are many comments below about the zsh ones. The new fish ones seem to be in the same boat...

fish documentation claims you can only install vendor_completions.d/*.fish for the command being completed, no autoloading if the command is "git" not "git-extras".

So there is nowhere to install this. Unless you have a suggestion that does NOT require users to source it in their ~/.zshrc or ~/.config/fish/config.fish

upstream added zsh and fish completions

could you please add them to this package

Please update to v6.

That's a pretty annoying trick. :/

Instead of a patch, I could set GIT_CONFIG=/dev/null make ... which would cause the Makefile to simply never find any aliases.

EDIT: done. No pkgrel update, if you managed to build it before (after maybe pressing "y") then you don't need to rebuild anyway, but this should make it more convenient in the future.

I always get this annoying prompt when building the package:

git-squash conflicts with an alias, still install it and disable the alias? [y/n]y

because I have an alias called squash in my git config.

IMHO the way the package is built should not depend on the user's configuration and certainly shouldn't it prompt unexpectedly for something interactively.

I suggest patching out lines 47-51 of the Makefile to remove this check.

The upstream Makefile doesn't deploy it either, because there's not exactly a defined place for such a thing. I'm not inventing some undocumented file location which no one knows about, myself, and I'm not going to spam users who don't care about zsh in order to tell them how to work around the failure to use zsh's completion system.

The well-documented completion systems exist for good reason, and the bash completions correctly integrate with it. If you need more, speak to upstream. Once the zsh ones work with the completion system, I'd be happy to install them to /usr/share/zsh/site-functions/.

From t he upstream Makefile:

    @echo "If you are a zsh user, you may want to 'source $(CODE_DIR)etc/git-extras-completion.zsh'" \
        "and put this line into ~/.zshrc to enable zsh completion"

This package doesn't deploy etc/git-extras-completion.zsh, I want it to, so I can source it and have completion in ZSH.

The git-extras project does not provide a zsh-completion file. Such files are traditionally installed to /usr/share/zsh/site-functions/_foo, and are loaded on-demand as documented here: http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Autoloaded-files

Instead there is a file which is manually sourced by the user's zshrc, and is totally incompatible with the builtin completion system.

This will not get installed, because there is nowhere to install it to.

And having a .install file modify the user's $HOME/.zshrc is a bannable offense, so I would not do that since then, as a TU, I'd be obligated to ban myself. ;)

Then make the PKGBUILD always install the ZSH completion?

No, what you're proposing is simply not possible.

The PKGBUILD is executed to BUILD the package, but what you're trying to determine something on the machine where the package will be installed.

Building and installation can happen in different machines. While you can use the .install file to achieve something like this, keep in mind that, generally, packages always install zsh-completion. This also helps in case the installation order is the opposite (first this, then zsh).

Is there an idiomatic way (from a PKGBUILD standpoint) to auto-detect if ZSH is installed, to deploy its completion file automatically?

Maybe something like if command -v zsh 2>&1 >/dev/null; then ….

No. git-extras-git is correctly marked as conflicting with this, doing it the other way around is both redundant and incorrect.

@Eschwartz Please add conflicts git-extras-git :)