Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)

[Samo Pogačnik <samo_pogacnik@t-2.net>]

Dne 06.05.2024 (pon) ob 15:02 +0200 je Daniel Gröber napisal(a):
> 
> Hmm. I'm not sure I like the idea of abusing libexec in this
> way. Technically speaking it's for "internal binaries that are not intended
> to be executed directly by users or shell scripts" this is clearly not the
> case here.
> 
> Looking over [git-* packages] to see what other packages do I see most git
> addons are in fact installed into /usr/bin.
> 
> [git-* packages]: 
> 
https://packages.debian.org/search?searchon=contents&keywords=git-&mode=filename&suite=stable&arch=any
> 
> Notable exception: git-absorb is still in lib/git-core and has [Bug#985775]
> which seems like it may be relevant to our problem. Have a read of it when
> you get the chance. Some snippets "Git changed the gitexecdir directory"
> maybe that change is what broke completion from git-core?  "... git-absorb
> works but git's bash completion doesn't suggest absorb" So they are aware
> of the completion issue already.
> 
> [Bug#985775]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985775

I also believe, this bug indicates the same problem. Unfortunately nothing have
changed since 2021. A reference to a git change in the bug report indicates that
one can add completion commands like:
git config --global completion.commands subrepo
I've tested that and it works, however i am not a fan of this solution, while
automatic detection of /usr/bin/git-* is available.

> 
> Anyway. I think the right solution here is to patch git-subrepo. IMO what's
> in git-subrepo.d really belongs in /usr/share/git-subrepo OR could just be
> concatenated into the main git-subrepo script, hmm. Bonus points for
> forwarding this bug and patch upstream.
> 

I prepared another change regarding git bash-completion integration using
"/usr/bin" and "/usr/share" in a similar way as some other packages (i.e. dcut,
dput, lintian, ...).

And yes it may be worth asking upstream how do they feel about the problem. For
now i've avoided touching upstream code, but if you prefer i can try to rework
the change in upstream code and produce first patch for the package.

--Samo