Re: git-ls-files(1) avoiding symlinks

[Alejandro Colomar <alx+git@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3284 bytes --]

Hi Junio,

> Date: 2026-11-06 12:16:48-0800
> From: Junio C Hamano <gitster@pobox.com>
>
> Alejandro Colomar <alx+git@kernel.org> writes:
> 
> >> > With -z it becomes a bit tedious:
> >> > 
> >> >    $ git ls-files -z --format='%(objectmode) %(path)' \
> >> >    | grep -zv ^120000 \
> >> >    | sed -z 's/^.* //' \
> >> >    | grep -z '\.[ch]$' \
> >> >    | xargs -0 grepc creat;
> 
> Shouldn't the grep|sed|grep be doable with a single sed invocation?
> 
> >> > I expect git-ls-files(1) could make this much simpler, though:
> >> > 
> >> >    $ git ls-files --type f \
> >> >    | grep '\.[ch]$' \
> >> >    | xargs grepc creat;
> 
> Not really.  Why is "--type" have to be so special?  What would the
> next person ask for?  --size?

Indeed.  While looking at the implementation of git-ls-files(1), I
realized it wasn't easy to decide how to implement this, as it has other
types (objecttype, which is blob/commit/...).  I thought perhaps
--objectmode, but then I'm not inderested in searching specific modes,
but rather filtering out some.  Perhaps in this case it's more
appropriate to have my own local command 'git-find' that does what
I want.

I've ended up doing this, and now don't think a flag in git-ls-files(1)
would make much sense.

	$ cat $(which git-find)
	#!/bin/bash
	# Copyright 2026, Alejandro Colomar <alx@kernel.org>
	# SPDX-License-Identifier: GPL-3.0-or-later

	set -Eeufo pipefail;

	git ls-files --format='%(objectmode) %(path)' \
	| grep -v '^120000' \
	| sed 's/^.* //';

And will eventually add a -z flag for this command when I find I need
it.

> The "ls-files" plumbing command is designed as a component to build
> your own pipeline with.  Don't throw in random unrelated features to
> it.  In the longer run, it is not a good substitute for improving
> the skill to construct a good pipeline.

Indeed.

> Learn the tools available to you that you already have heard of, so
> that you can make better uses of them (in this case "sed").  If you
> squash the grep|sed|grep pipeline into a single sed
> 
>     git ls-files -z -s "*.[ch]" |
>     sed -z -n -e '/^120000/d' -e '/^.* 0	/s///p' |
>     xargs -r -0 ls -ld
> 
> the result does not look too bad.

I find it simpler to have a simple grep -v rejecting the lines I don't
want, and then sed(1) getting rid of the stuff.  The command above seems
interesting for performance, but compared to the tool using the file
names, that's probably negligible.

About git-ls-files(1)'s -s, I think it's easier to parse with the
%(objectmode) in the format, as I don't need all the other information
printed by -s.

> 
> One unrelated tip for better readability is to end, not begin, your
> lines with the "|" pipe characters.  That way you do not have to
> sprinkle so many unsightly backslashes ;-).

I like to have them at the front of the line because it shows more
clearly whether I'm piping a command or starting a new pipeline.  I got
used to the backslashes.  After all, the first few characters of a line
are all aligned, and the most significant ones.  Stuff to the right I
tend to ignore it as noise.  :)

> 
> HTH.

Yup!  Thanks!


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]