accept short hashes for `--at`

[KiaraGrouwstra]

currently, if one passes a short revision hash to the --at flag of npins add, one is met with the error '{revision}' is not a valid git revision (sha1 hash).
given the likes of hydra would communicate short hashes (e.g. 'Input changes' column at their jobset page), it would be cool if npins accepted these as well.

whether this is technically feasible / practical tho, i don't know.

edit: git rev-parse <revision> seems relevant

[piegamesde]

The check was introduced in 6f8bcc9 because of #75. I think a solution that simply adapts the length check without going full git rev-parse would be fine here

[KFearsoff]

I have tried my hand at it, and I've ran into some issues.

So ideally, to have this feature work correctly, it should work like this: --at is passed in the CLI, it is validated to be either short or long hash, and the short hash should be an intermediate value that is upgraded to be a full hash during the fetching, and then the full hash is saved to the lockfile.

This is mostly possible, but currently, npins functions update (use newest commit) and fetch (take the Nix hash related to that commit) are split between using DIY git operations and using nix-prefetch-git script from Nixpkgs. The major roadblock is that git rev-parse doesn't work on remote repositories, and in general, there is no way to "fetch" a commit corresponding to the short SHA from a remote. So we need to do the clone, which is more expensive, and run git rev-parse on that checkout.

This already makes it a no-go for Nixpkgs pins, but it gets worse. nix-prefetch-git already does a clone, and it does it in a temporary directory that it itself cleans up, so there's no way to reuse between them, or utilize caching of any sort. To make Nixpkgs clones faster, npins uses nix-prefetch-tarball with the tarball of a concrete Nixpkgs revision, but without mapping to long SHA, it's also impossible :/

[KiaraGrouwstra]

the nix-prefetch-git behavior sounds like stuff that would be nice to see fixed on their side.

on trouble with the git rev-parse strategy for remote repos, i imagine forge-specific API endpoints could help make this viable for common forges such as nixpkgs' github, even if we couldn't handle it right even in the general git case.

[piegamesde]

I think this ties in well with #148 where we want to move away from external helpers and do our own temp download for better control