bug#65924: git searches coreutils and util-linux commands in PATH

[Liliana Marie Prikler]

Am Montag, dem 09.10.2023 um 23:03 +0200 schrieb b...@bokr.com:
> Hi,
> 
> On +2023-10-09 20:33:38 +0200, Liliana Marie Prikler wrote:
> > I don't necessarily agree, but it's not a hard disagree either. 
> > I'll try to keep that in mind at least when reviewing your patches
> > to not cause confusion.
> > 
> > Cheers
> > 
> 
> TL;DR: Would it make sense to anticipate that LLM-bots will be used
> to automate gathering of info for reviewers?
> 
> If so, what would a style guide for english in posts (like
> a coding style guide, but for LLM-bot consumption) look like?
> Some kind of literate programming for LLM-bot and human use?
Let's not rely on large language models.  If we are going to automate
this, it ought to be through interpretable, "rule-based" systems. 
Like, imagine that on top of telling debbugs to close a bug etc., you
could tell debbugs (or some other tool) that some patch or a series
looks good to you.  We could then add an interface to allow filtering
for "looks good" series for quick patch application, the rationale
being that committers have to do less or no review of their own as they
commit to a patch or series.*

Cheers

* They should still check that the series actually looks good to enough
folks.

bug#65924: git searches coreutils and util-linux commands in PATH

[bokr]

Hi,

On +2023-10-09 20:33:38 +0200, Liliana Marie Prikler wrote:
> Am Montag, dem 09.10.2023 um 14:21 -0400 schrieb Maxim Cournoyer:
> > Hello,
> > 
> > Liliana Marie Prikler  writes:
> > 
> > > [...]
> > > If you need me to reduce it to four letters, yes, LGTM.
> > 
> > Explicit is better than implicit.  I've been thinking to document
> > this in our contributing section; e.g. a reviewed commit must have
> > the 'LGTM' from the reviewer.  If a series is LGTM, it needs to be
> > implicitly mentioned with 'this series LGTM'.  That may sound silly,
> > but I think it'd simplify reviewer/submitters interactions.
> s/implicitly/explicitly/?
> 
> I don't necessarily agree, but it's not a hard disagree either.  I'll
> try to keep that in mind at least when reviewing your patches to not
> cause confusion.
> 
> Cheers
>

TL;DR: Would it make sense to anticipate that LLM-bots will be used
to automate gathering of info for reviewers?

If so, what would a style guide for english in posts (like
a coding style guide, but for LLM-bot consumption) look like?
Some kind of literate programming for LLM-bot and human use?

(I assume experiments have been going on by now, though perhaps
not yet for guile or guix)
--
Regards,
Bengt Richter

bug#65924: git searches coreutils and util-linux commands in PATH

[Maxim Cournoyer]

Hello,

Liliana Marie Prikler  writes:

> Am Montag, dem 09.10.2023 um 15:25 -0400 schrieb Maxim Cournoyer:
>> Hi Liliana,
>> 
>> Liliana Marie Prikler  writes:
>> 
>> > Am Montag, dem 09.10.2023 um 14:21 -0400 schrieb Maxim Cournoyer:
>> > > Hello,
>> > > 
>> > > Liliana Marie Prikler  writes:
>> > > 
>> > > > [...]
>> > > > If you need me to reduce it to four letters, yes, LGTM.
>> > > 
>> > > Explicit is better than implicit.  I've been thinking to document
>> > > this in our contributing section; e.g. a reviewed commit must
>> > > have the 'LGTM' from the reviewer.  If a series is LGTM, it needs
>> > > to be implicitly mentioned with 'this series LGTM'.  That may
>> > > sound silly, but I think it'd simplify reviewer/submitters
>> > > interactions.
>> > s/implicitly/explicitly/?
>> 
>> Explicit, indeed.
>> 
>> > I don't necessarily agree, but it's not a hard disagree either. 
>> > I'll try to keep that in mind at least when reviewing your patches
>> > to not cause confusion.
>> 
>> OK.  One place where this becomes more important is when the send-
>> email cc hook includes people partially to a series. A LGTM on a
>> single message in this case could be misinterpreted for the whole
>> series.  It's best to document the expectations and codify these
>> often used signals, in my opinion.
> I personally prefer to comment to all individual patches or use the
> series starter for "this series LGTM", but to recap; 1 and 2 L'd GTM
> (with a small caveat for 1) already and we discussed 3 in IRC, so LGTM
> for the series.

That's a good idea.

Thanks for the heads-up!  I've now installed this series to
core-updates.  Closing!

-- 
Thanks,
Maxim

bug#65924: git searches coreutils and util-linux commands in PATH

[Liliana Marie Prikler]

Am Montag, dem 09.10.2023 um 15:25 -0400 schrieb Maxim Cournoyer:
> Hi Liliana,
> 
> Liliana Marie Prikler  writes:
> 
> > Am Montag, dem 09.10.2023 um 14:21 -0400 schrieb Maxim Cournoyer:
> > > Hello,
> > > 
> > > Liliana Marie Prikler  writes:
> > > 
> > > > [...]
> > > > If you need me to reduce it to four letters, yes, LGTM.
> > > 
> > > Explicit is better than implicit.  I've been thinking to document
> > > this in our contributing section; e.g. a reviewed commit must
> > > have the 'LGTM' from the reviewer.  If a series is LGTM, it needs
> > > to be implicitly mentioned with 'this series LGTM'.  That may
> > > sound silly, but I think it'd simplify reviewer/submitters
> > > interactions.
> > s/implicitly/explicitly/?
> 
> Explicit, indeed.
> 
> > I don't necessarily agree, but it's not a hard disagree either. 
> > I'll try to keep that in mind at least when reviewing your patches
> > to not cause confusion.
> 
> OK.  One place where this becomes more important is when the send-
> email cc hook includes people partially to a series. A LGTM on a
> single message in this case could be misinterpreted for the whole
> series.  It's best to document the expectations and codify these
> often used signals, in my opinion.
I personally prefer to comment to all individual patches or use the
series starter for "this series LGTM", but to recap; 1 and 2 L'd GTM
(with a small caveat for 1) already and we discussed 3 in IRC, so LGTM
for the series.

Cheers

bug#65924: git searches coreutils and util-linux commands in PATH

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler  writes:

> Am Montag, dem 09.10.2023 um 14:21 -0400 schrieb Maxim Cournoyer:
>> Hello,
>> 
>> Liliana Marie Prikler  writes:
>> 
>> > [...]
>> > If you need me to reduce it to four letters, yes, LGTM.
>> 
>> Explicit is better than implicit.  I've been thinking to document
>> this in our contributing section; e.g. a reviewed commit must have
>> the 'LGTM' from the reviewer.  If a series is LGTM, it needs to be
>> implicitly mentioned with 'this series LGTM'.  That may sound silly,
>> but I think it'd simplify reviewer/submitters interactions.
> s/implicitly/explicitly/?

Explicit, indeed.

> I don't necessarily agree, but it's not a hard disagree either.  I'll
> try to keep that in mind at least when reviewing your patches to not
> cause confusion.

OK.  One place where this becomes more important is when the send-email
cc hook includes people partially to a series. A LGTM on a single
message in this case could be misinterpreted for the whole series.  It's
best to document the expectations and codify these often used signals,
in my opinion.

-- 
Thanks,
Maxim

bug#65924: git searches coreutils and util-linux commands in PATH

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler  writes:

> Am Montag, dem 09.10.2023 um 10:21 -0400 schrieb Maxim Cournoyer:
>> Hi Liliana :-)
>> 
>> Liliana Marie Prikler  writes:
>> 
>> > Am Samstag, dem 07.10.2023 um 23:18 -0400 schrieb Maxim Cournoyer:
>> > > It's simpler to add features on top of a minimal variant than to
>> > > remove them, and helps avoiding mistakenly changing git-minimal,
>> > > which has many dependents.
>> > > 
>> > > * gnu/packages/version-control.scm (git-minimal): Move above git
>> > > and severe inheritance.  Remove input label.  Repatriate most
>> > > fields from...
>> > > (git): ... here.  Define as package/inherit to inherit from git-
>> > > minimal.
>> > > Extend minimal values instead of overriding them whole.
>> > > ---
>> > Having done the same to Emacs recently, I fully agree with this
>> > move.
>> 
>> Great; does this mean a LGTM on your side for this one?  Please be
>> explicit :-).
> If you need me to reduce it to four letters, yes, LGTM.

Just to make sure, the LGTM is for the whole series?

-- 
Thanks,
Maxim

bug#65924: git searches coreutils and util-linux commands in PATH

[Liliana Marie Prikler]

Am Montag, dem 09.10.2023 um 14:21 -0400 schrieb Maxim Cournoyer:
> Hello,
> 
> Liliana Marie Prikler  writes:
> 
> > [...]
> > If you need me to reduce it to four letters, yes, LGTM.
> 
> Explicit is better than implicit.  I've been thinking to document
> this in our contributing section; e.g. a reviewed commit must have
> the 'LGTM' from the reviewer.  If a series is LGTM, it needs to be
> implicitly mentioned with 'this series LGTM'.  That may sound silly,
> but I think it'd simplify reviewer/submitters interactions.
s/implicitly/explicitly/?

I don't necessarily agree, but it's not a hard disagree either.  I'll
try to keep that in mind at least when reviewing your patches to not
cause confusion.

Cheers

bug#65924: git searches coreutils and util-linux commands in PATH

[Maxim Cournoyer]

Hello,

Liliana Marie Prikler  writes:

> Am Montag, dem 09.10.2023 um 10:21 -0400 schrieb Maxim Cournoyer:
>> Hi Liliana :-)
>> 
>> Liliana Marie Prikler  writes:
>> 
>> > Am Samstag, dem 07.10.2023 um 23:18 -0400 schrieb Maxim Cournoyer:
>> > > It's simpler to add features on top of a minimal variant than to
>> > > remove them, and helps avoiding mistakenly changing git-minimal,
>> > > which has many dependents.
>> > > 
>> > > * gnu/packages/version-control.scm (git-minimal): Move above git
>> > > and severe inheritance.  Remove input label.  Repatriate most
>> > > fields from...
>> > > (git): ... here.  Define as package/inherit to inherit from git-
>> > > minimal.
>> > > Extend minimal values instead of overriding them whole.
>> > > ---
>> > Having done the same to Emacs recently, I fully agree with this
>> > move.
>> 
>> Great; does this mean a LGTM on your side for this one?  Please be
>> explicit :-).
> If you need me to reduce it to four letters, yes, LGTM.

Explicit is better than implicit.  I've been thinking to document this
in our contributing section; e.g. a reviewed commit must have the 'LGTM'
from the reviewer.  If a series is LGTM, it needs to be implicitly
mentioned with 'this series LGTM'.  That may sound silly, but I think
it'd simplify reviewer/submitters interactions.

-- 
Thanks,
Maxim

bug#65924: git searches coreutils and util-linux commands in PATH

[Liliana Marie Prikler]

Am Montag, dem 09.10.2023 um 10:21 -0400 schrieb Maxim Cournoyer:
> Hi Liliana :-)
> 
> Liliana Marie Prikler  writes:
> 
> > Am Samstag, dem 07.10.2023 um 23:18 -0400 schrieb Maxim Cournoyer:
> > > It's simpler to add features on top of a minimal variant than to
> > > remove them, and helps avoiding mistakenly changing git-minimal,
> > > which has many dependents.
> > > 
> > > * gnu/packages/version-control.scm (git-minimal): Move above git
> > > and severe inheritance.  Remove input label.  Repatriate most
> > > fields from...
> > > (git): ... here.  Define as package/inherit to inherit from git-
> > > minimal.
> > > Extend minimal values instead of overriding them whole.
> > > ---
> > Having done the same to Emacs recently, I fully agree with this
> > move.
> 
> Great; does this mean a LGTM on your side for this one?  Please be
> explicit :-).
If you need me to reduce it to four letters, yes, LGTM.

bug#65924: git searches coreutils and util-linux commands in PATH

[Maxim Cournoyer]

Hi,

Maxim Cournoyer  writes:

> This series introduces default variable bindings for the default
> gnu-build-system IMPORTED-MODULES and MODULES values.  The lack of a
> %default-gnu-modules caused enough confusion, as made apparent by this series.
>
> Maxim Cournoyer (65):

Nevermind the above mis-sent series; it should have been sent to a new
issue.  Apologies for the noise!  Your review on 'git searches
coreutils and util-linux commands in PATH' in this series is still
needed, though :-)

-- 
Thanks,
Maxim

bug#65924: git searches coreutils and util-linux commands in PATH

[Maxim Cournoyer]

Hi Liliana :-)

Liliana Marie Prikler  writes:

> Am Samstag, dem 07.10.2023 um 23:18 -0400 schrieb Maxim Cournoyer:
>> It's simpler to add features on top of a minimal variant than to
>> remove them, and helps avoiding mistakenly changing git-minimal,
>> which has many dependents.
>> 
>> * gnu/packages/version-control.scm (git-minimal): Move above git and
>> severe inheritance.  Remove input label.  Repatriate most fields
>> from...
>> (git): ... here.  Define as package/inherit to inherit from git-
>> minimal.
>> Extend minimal values instead of overriding them whole.
>> ---
> Having done the same to Emacs recently, I fully agree with this move.

Great; does this mean a LGTM on your side for this one?  Please be
explicit :-).

-- 
Thanks,
Maxim

bug#65924: git searches coreutils and util-linux commands in PATH

[Simon Tournier]

Hi,

On Wed, 04 Oct 2023 at 23:41, Maxim Cournoyer  wrote:

>> I think we should add coreutils-minimal and sed (or gash-utils?) to the
>> ‘git-submodule’ wrapper that already exists.
>
> That should work for the use case at hand, but we should scan the source
> for occurrences of the tools to see if other git commands need to be
> wrapped as well.  This doesn't also cover 'uname' from my report, which
> should be looked into as well (when is it needed? is it a fatal error if
> it's missing? etc.)

Well, ’git-submodule’ is just a shell script.  It depends on:

  + basename
  + sed
  + git-sh-setup which depends on:
 + basename
 + sed
 + uname

And all these other subcommands match ’git-sh-setup’:

Binary:

 + bin/git
 + bin/scalar
 + libexec/git-core/git
 + libexec/git-core/scalar

Scripts:

 + libexec/git-core/git-filter-branch
 + libexec/git-core/git-merge-octopus
 + libexec/git-core/git-merge-one-file
 + libexec/git-core/git-merge-resolve
 + libexec/git-core/git-mergetool
 + libexec/git-core/git-quiltimport
 + libexec/git-core/git-submodule
 + libexec/git-core/git-web--browse
 + libexec/git-core/git-web--browse

For instance, libexec/git-core/git-mergetools/emerge or
libexec/git-core/git-mergetools/tortoisemerge depends on ’basename’.

This ’git-sh-setup’ is dragged into the picture by the file
’command-list.h’ which basically provides some help.  See below.

Last, I think ’git-sh-setup’ fails if ’uname’ is missing.


Cheers,
simon

--8<---cut here---start->8---
# From Git checkout

$ cat git-submodule | grep -n -E '(basename|sed|uname)'
7:dashless=$(basename "$0" | sed -e 's/-/ /')
569:# parsed here as well, for backward compatibility.
613:"cmd_$(echo $command | sed -e s/-/_/g)" "$@"

$ cat git-sh-setup | grep -n -E '(basename|sed|uname)'
77: dashless=$(basename -- "$0" | sed -e 's/-/ /')
181:die "$(eval_gettext "fatal: \$program_name cannot be used 
without a working tree.")"
188:die "$(eval_gettext "fatal: \$program_name cannot be used 
without a working tree.")"
230:# Generate a sed script to parse identities from a commit.
264:# Create a pick-script as above and feed it to sed. Stdout is suitable for
267:LANG=C LC_ALL=C sed -ne "$(pick_ident_script "$@")"
292:case $(uname -s) in

$ find $(guix build git-minimal --no-grafts) -type f -exec grep -nH 
git-sh-setup {} \; | sort
grep: /gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/bin/git: 
binary file matches
grep: 
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/bin/scalar: 
binary file matches
grep: 
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git:
 binary file matches
grep: 
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/scalar:
 binary file matches
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-filter-branch:109:.
 git-sh-setup
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-merge-octopus:8:.
 git-sh-setup
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-merge-one-file:26:.
 git-sh-setup
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-merge-resolve:8:.
 git-sh-setup
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-mergetool:17:.
 git-sh-setup
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-quiltimport:14:.
 git-sh-setup
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-submodule:22:.
 git-sh-setup
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-web--browse:22:#
 the vanilla git-sh-setup should not be used.
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-web--browse:24:.
 git-sh-setup

$ find . -type f -name "*.[ch]" -exec grep -nH git-sh-setup {} \;
./command-list.h:171:   { "git-sh-setup", N_("Common Git shell script setup 
code"), 0 | CAT_purehelpers },

$ find . -type f -name "*.o" -exec grep -nH git-sh-setup {} \;
grep: ./help.o: binary file matches

$ grep git-sh-setup git
grep: git: binary file matches

$ grep -B 5 -A 10 -n uname $(guix build git-minimal 
--no-grafts)/libexec/git-core/git-sh-setup
287-expr $sz0 \< $sz1 \* 2 >/dev/null || : >"$1"
288-}
289-
290-
291-# Platform specific tweaks to work around some commands
292:case $(uname -s) in
293-*MINGW*)
294-# Windows has its own (incompatible) sort and find
295-sort () {
296-/usr/bin/sort "$@"
297-}
298-find () {
299-/usr/bin/find "$@"
300-}
301-# git sees Windows-style pwd
302-pwd () {
--8<---cut here---end--->8---

bug#65924: git searches coreutils and util-linux commands in PATH

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> Attempting to use git-minimal in a --pure environment, I stumbled upon:
>>
>> /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule:
>> line 7: basename: command not found
>> /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule:
>> line 7: sed: command not found
>> /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-sh-setup:
>> line 77: basename: command not found
>> /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-sh-setup:
>> line 77: sed: command not found
>> /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-sh-setup:
>> line 292: uname: command not found
>> /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule:
>> line 613: sed: command not found
>> /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule:
>> line 613: cmd_: command not found
>> ☒ git clone exited 127
>>
>> The 'git' command should be wrapped to include these in its PATH.
>
> I think we should add coreutils-minimal and sed (or gash-utils?) to the
> ‘git-submodule’ wrapper that already exists.

That should work for the use case at hand, but we should scan the source
for occurrences of the tools to see if other git commands need to be
wrapped as well.  This doesn't also cover 'uname' from my report, which
should be looked into as well (when is it needed? is it a fatal error if
it's missing? etc.)

-- 
Thanks,
Maxim

bug#65924: git searches coreutils and util-linux commands in PATH

[Simon Tournier]

Hi,

On Wed, 04 Oct 2023 at 18:14, Ludovic Courtès  wrote:

> I think we should add coreutils-minimal and sed (or gash-utils?) to the
> ‘git-submodule’ wrapper that already exists.

Yes, for now it is seems the way forward for fixing the current #66305.

It is an increase of git-minimal about ~12%.


> Closure size is a concern, as Simon notes.  Longer-term we should make
> coreutils-minimal more minimal, perhaps by stripping it of l10n data.

About gash-utils, well currently broken so…

https://ci.guix.gnu.org/build/2072492/details

And it would drag Guile in the picture, no?  And ’sed’ seems an order
more minimalist than Guile, no?

For sure, more git-minimal is, happier people will be.


Cheers,
simon

bug#65924: git searches coreutils and util-linux commands in PATH

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Attempting to use git-minimal in a --pure environment, I stumbled upon:
>
> /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule:
>  line 7: basename: command not found
> /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule:
>  line 7: sed: command not found
> /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-sh-setup:
>  line 77: basename: command not found
> /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-sh-setup:
>  line 77: sed: command not found
> /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-sh-setup:
>  line 292: uname: command not found
> /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule:
>  line 613: sed: command not found
> /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule:
>  line 613: cmd_: command not found
> ☒ git clone exited 127
>
> The 'git' command should be wrapped to include these in its PATH.

I think we should add coreutils-minimal and sed (or gash-utils?) to the
‘git-submodule’ wrapper that already exists.

Closure size is a concern, as Simon notes.  Longer-term we should make
coreutils-minimal more minimal, perhaps by stripping it of l10n data.

But first: let’s fix this so we can address
.

Ludo’.

bug#65924: git searches coreutils and util-linux commands in PATH

[Simon Tournier]

Hi,

On Thu, 14 Sept 2023 at 05:14, Maxim Cournoyer
 wrote:

> > $ guix size git-minimal
> > [...]
> > total: 147.8 MiB
> >
> > $ guix size git-minimal util-linux coreutils
> > [...]
> > total: 195.4 MiB
> >
> > It increases the size by 33% which is not nothing. :-)

[...]

> > The question could be: is worth to add 33% for these commands?

[...]

> References are also found in bin/git in your search, which suggests
> perhaps the size of git-minimal is a "lie" (the core package is not
> fully functional).

Only coreutils is about 165.1 MiB so 12% which is better than 33% but
not nothing either; especially if git-mininal becomes an hard
dependency of Guix (as proposed in e.g. patch##65866 [1]).

Another fix could be that git-minimal does not provide the "git
submodule" subcommand for example; or other ones.  I have not
considered that yet and I am not plainly proposing that; somehow I
would like to avoid to have a git-minimal that would not be really
"minimal" for features that are not minimalist :-)

Cheers,
simon

1: [bug#65866] [PATCH 0/8] Add built-in builder for Git checkouts
Ludovic Courtès 
Mon, 11 Sep 2023 16:23:42 +0200
id:cover.1694441830.git.l...@gnu.org
https://issues.guix.gnu.org//65866
https://issues.guix.gnu.org/msgid/cover.1694441830.git.l...@gnu.org
https://yhetil.org/guix/cover.1694441830.git.l...@gnu.org

bug#65924: git searches coreutils and util-linux commands in PATH

[Maxim Cournoyer]

Hi,

Simon Tournier  writes:

> Hi Maxim,
>
> On Wed, 13 Sep 2023 at 14:00, Maxim Cournoyer  
> wrote:
>
>> The 'git' command should be wrapped to include these in its PATH.
>
> $ guix size git-minimal
> [...]
> total: 147.8 MiB
>
> $ guix size git-minimal util-linux coreutils
> [...]
> total: 195.4 MiB
>
>
> It increases the size by 33% which is not nothing. :-)
>
> Is it only the subcommand git-submodule which is broken?  Probably not.
>
> $ find $(guix build git-minimal --no-grafts) -type f -exec grep -H 
> git-sh-setup {} \; | cut -f1 -d':' | xargs -I {} basename {}
> grep: 
> /gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/bin/scalar: 
> binary file matches
> grep: /gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/bin/git: 
> binary file matches
> grep: 
> /gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/scalar:
>  binary file matches
> grep: 
> /gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git:
>  binary file matches
> git-submodule
> git-filter-branch
> git-merge-resolve
> git-mergetool
> git-merge-octopus
> git-merge-one-file
> git-web--browse
> git-web--browse
> git-quiltimport
>
> The question could be: is worth to add 33% for these commands?

I'm not sure where uname is needed; we'd have to check.  util-linux is
where most of the weigh increase is at.  'git submodule' is part of
git-minimal; it should work without external tools, ideally.

References are also found in bin/git in your search, which suggests
perhaps the size of git-minimal is a "lie" (the core package is not
fully functional).

-- 
Thanks,
Maxim

bug#65924: git searches coreutils and util-linux commands in PATH

[Simon Tournier]

Hi Maxim,

On Wed, 13 Sep 2023 at 14:00, Maxim Cournoyer  wrote:

> The 'git' command should be wrapped to include these in its PATH.

--8<---cut here---start->8---
$ guix size git-minimal
[...]
total: 147.8 MiB

$ guix size git-minimal util-linux coreutils
[...]
total: 195.4 MiB
--8<---cut here---end--->8---

It increases the size by 33% which is not nothing. :-)

Is it only the subcommand git-submodule which is broken?  Probably not.

--8<---cut here---start->8---
$ find $(guix build git-minimal --no-grafts) -type f -exec grep -H git-sh-setup 
{} \; | cut -f1 -d':' | xargs -I {} basename {}
grep: 
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/bin/scalar: 
binary file matches
grep: /gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/bin/git: 
binary file matches
grep: 
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/scalar:
 binary file matches
grep: 
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git:
 binary file matches
git-submodule
git-filter-branch
git-merge-resolve
git-mergetool
git-merge-octopus
git-merge-one-file
git-web--browse
git-web--browse
git-quiltimport
--8<---cut here---end--->8---

The question could be: is worth to add 33% for these commands?

Cheers,
simon

bug#65924: git searches coreutils and util-linux commands in PATH

[Maxim Cournoyer]

Hello,

Attempting to use git-minimal in a --pure environment, I stumbled upon:

--8<---cut here---start->8---
/gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule:
 line 7: basename: command not found
/gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule:
 line 7: sed: command not found
/gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-sh-setup:
 line 77: basename: command not found
/gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-sh-setup:
 line 77: sed: command not found
/gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-sh-setup:
 line 292: uname: command not found
/gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule:
 line 613: sed: command not found
/gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule:
 line 613: cmd_: command not found
☒ git clone exited 127
--8<---cut here---end--->8---

The 'git' command should be wrapped to include these in its PATH.

-- 
Thanks,
Maxim