From: Ben Knoble <ben.knoble@gmail.com>
Date: Tue, 23 Sep 2025 16:57:04 GMT
Subject: Re: [GSoC][PATCH] builtin/refs: add 'get' subcommand
Message-ID: <ABB734D1-EAB4-429C-9A36-C00E114E4207@gmail.com>
In-Reply-To: <20250923104533.21165-1-meetsoni3017@gmail.com>

With apologies if I cover well-trodden ground, as I haven’t been closely following this effort.

> Le 23 sept. 2025 à 06:47, Meet Soni <meetsoni3017@gmail.com> a écrit :
> 
> While `git-rev-parse(1)` and `git-show-ref(1)` can be used to read
> reference values, they have drawbacks for scripting and discoverability.
> `rev-parse` performs DWIM expansion which is unpredictable for scripts,

[snip]

> To address this, introduce a new plumbing command, `git refs get <ref>`.
> This new command provides three key advantages:
> 
>  - It requires an exact refname and does not perform expansion, making
>    it safer and more predictable for scripting.

What are the disadvantages of rev-parse’s DWIMmery in scripts? I would think it makes handling user input easier (e.g., my custom script can take a local branch name without writing « refs/heads/ » on the command-line). OTOH, a script that wants to precisely identify a ref can do so already, no?

Since rev-parse presumably won’t go away, it might be ok to have 2 ways of parsing (one with magic and one without), but that might be back to the same boat of not having a unified interface 😅

Perhaps later we can add a « --dwim » flag for looser parsing, giving scripteds flexibility but strictness by default?