[bug#57858] [PATCH] gnu: git-annex: Promote git to propagated input

[zimoun]

Hi Konrad,

On lun., 17 oct. 2022 at 12:11, Konrad Hinsen <konrad.hinsen@fastmail.net> 
wrote:

> But you are right in pointing out that this is an instance of a
> situation for which Guix should have a general policy. git-lfs is
> probably in exactly the same situation. Not emacs-magit though: it works
> perfectly fine without exposing git in the same profile. Being a git
> plugin is not the same as being a git wrapper.

>From my understanding, the general policy is to not propagate git. :-)

>From gnu/packages/version-control.scm, where xyz: is the line number

--8<---------------cut here---------------start------------->8---
778:(define-public git-cal                     no inputs
907:(define-public git-crypt                   inputs: git
960:(define-public git-remote-gcrypt           no inputs
1108:(define-public python-git-multimail       inputs: git
1311:(define-public git-flow                   inputs: no git
1451:(define-public git-test-sequence          no inputs
2681:(define-public git-annex-remote-rclone    inputs: no git
2901:(define-public git-when-merged            inputs: git
2952:(define-public git-imerge                 inputs: git
2997:(define-public git-lfs                    native-inputs only and no git
3046:(define-public git-open                   inputs: no git
3392:(define-public git-filter-repo            inputs: no git
--8<---------------cut here---------------end--------------->8---

The package git-repo from (gnu packages android) contains git as
inputs.  The package git-absord from (gnu packages rust-apps) does not
contains git as inputs.


I understand the issue but I think the propagation is not the correct
solution. :-)


Cheers,
simon