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.  I'd say prioritize commit hashes over tags and not sure if a
:tag keyword would just act as documentation or a comment or just use a
comment?