Stéphane Marks <shipmints@gmail.com> writes:

> On Fri, Jun 20, 2025 at 6:39 PM Peter Oliver <p.d.oliver@mavit.org.uk>
> wrote:
>
>> On Jun 8, 2025, at 10:45 AM, Juri Linkov <juri <at> linkov.net> wrote:
>>
>> > Here is the current state:
>> >
>> > 3. (treesit--install-language-grammar-1
>> >    (locate-user-emacs-file "tree-sitter") 'json
>> >    "https://github.com/tree-sitter/tree-sitter-json"
>> >    "4d770d3")
>> >
>> >  fails to check out "4d770d3" with the error:
>> >
>> >  git clone https://github.com/tree-sitter/tree-sitter-json --quiet
>> --depth 1 -b 4d770d3
>> >  warning: Could not find remote branch 4d770d3 to clone
>> >  fatal: Remote branch 4d770d3 not found in upstream origin
>>
>> I’m a bit late to the party, here, but would it make sense to have, say:
>>
>>    (treesit--install-language-grammar-1
>>     (locate-user-emacs-file "tree-sitter") 'json
>>     "https://github.com/tree-sitter/tree-sitter-json"
>>     :tag "v0.24.8"
>>     :commit "4d770d31f732d50d3ec373865822fbe659e47c75")
>>
>> We could then:
>>
>>    git clone https://github.com/tree-sitter/tree-sitter-json --quiet
>> --depth 1 -b v0.24.8
>>    git checkout 4d770d31f732d50d3ec373865822fbe659e47c75
>>
>> Additionally, I think including the tag helps to clarify the intention to
>> anyone reading the code, without them having to go away and refer to the
>> repository to find out about that commit.
>
>
> git tags aren't really immutable, though, as they can be changed to point
> to other commits.  If you want to specify both a commit hash and a tag and
> the tag doesn't or no longer points to that commit, that would be
> confusing.

Or an error. I guess you could include tag names to allow for some kind
of UX shorthand while verifying, using the hashes, that the tags still
refer to their designated trees.