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?