Re: Discussion on git-refs list Implementation and Possible Approaches

From: Yuting Zheng <05zyt30@gmail.com>
Date: Apr 4, 2025, 15:25 UTC
Message-ID: <CAMvj1+paWq5LV1imUz0HcQh1eoGvdfkYi0B5FPV33Xt-OUe1Dg@mail.gmail.com>
In-Reply-To: <CAOLa=ZTTPuNyaE5Z-bfkQougmKQSrRZZwLaxJUL7mdmj8uHoFw@mail.gmail.com>

Thanks for your reply!

> I would categorize '--sort' into a third subcategory. Filtering refers
> to possible change in the size of the sample set. While sorting is more
> of a presentation utility.
>

That’s a good idea, it makes my plan more clear. I will separate the “--filter” options into “--filter” and “--sort” so that users can clearly distinguish them.

> This is indeed a special case which applies to both sorting and
> filtering.

Understood!

Show 8 quoted lines

>
> You mean complex from the user perspective of having too many options or
> from the implementation perspective.
>
> I think from the UX perspective, it is a good time to rethink usage and
> need for the options you mentioned above. , for e.g. with '--format', do
> we need to have '--tcl', `--shell` and `--perl`?
>

I think it’s important to discuss all available options, and I will submit another email for further discussion.

Show 37 quoted lines

> > 2. The performance could be worse than `git-for-each-ref`.
> >
>
> Why would it be worse? The performance difference between
> `git-for-each-ref(1)` and `git-show-ref(1)` stem from the formats they
> use by default.
>
> $ hyperfine --shell=none --warmup=3 "git for-each-ref" "git show-ref"
> Benchmark 1: git for-each-ref
>   Time (mean ± σ):       4.0 ms ±   0.6 ms    [User: 1.9 ms, System: 1.9 ms]
>   Range (min … max):     3.0 ms …   5.7 ms    680 runs
>
> Benchmark 2: git show-ref
>   Time (mean ± σ):       2.9 ms ±   0.4 ms    [User: 1.2 ms, System: 1.5 ms]
>   Range (min … max):     2.0 ms …   4.3 ms    909 runs
>
> Summary
>   git show-ref ran
>     1.38 ± 0.28 times faster than git for-each-ref
>
> What I found interesting was that changing the format for
> 'git-for-each-ref(1)' gives it a boost:
>
> $ hyperfine --shell=none --warmup=3 'git for-each-ref
> --format="%(objectname) %(refname)"' "git show-ref"
> Benchmark 1: git for-each-ref --format="%(objectname) %(refname)"
>   Time (mean ± σ):       2.4 ms ±   0.3 ms    [User: 1.1 ms, System: 1.1 ms]
>   Range (min … max):     1.7 ms …   3.6 ms    1070 runs
>
> Benchmark 2: git show-ref
>   Time (mean ± σ):       2.9 ms ±   0.4 ms    [User: 1.2 ms, System: 1.5 ms]
>   Range (min … max):     2.0 ms …   4.5 ms    833 runs
>
> Summary
>   git for-each-ref --format="%(objectname) %(refname)" ran
>     1.20 ± 0.23 times faster than git show-ref
>

Thank you for the reminder. Once each option is implemented, I will test its performance to ensure that it maintains—or improves upon—the efficiency of the previous version.

Show 13 quoted lines

>
> And what is the expectation that when you want to do both filtering and
> formatting, would the user be expected to do `git refs filter | git refs
> show`? Generally users want to combine both of these options.
>
> Also wasn't the idea to already implement `git-refs show` as a
> standalone which simply shows what value a reference holds (without
> derefence)?
>
> While I would think Approach 1 is the better option here, I'm also
> seeing how it is complex, perhaps a good option to get started would be
> to implement a simpler subcommand as a first case? Perhaps the
> originally discussed `git refs show`?

I agree that implementing `git-refs show` first would provide a solid foundation for other options. I will add these improvements in the next version of the proposal.

Thanks! Zheng Yuting