-
-
Notifications
You must be signed in to change notification settings - Fork 381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resolving "refish" #922
Comments
hmm, 👷 digs |
Yeah, definitely doesn't work: via DWIM: reference = repo.lookup_reference_dwim('master') # lookup_reference() raises InvalidSpecError
assert reference.name == 'refs/heads/master'
reference = repo.lookup_reference_dwim('origin/master') # lookup_reference() raises InvalidSpecError
assert reference.name == 'refs/remotes/origin/master'
reference = repo.lookup_reference_dwim('version1') # lookup_reference() raises InvalidSpecError
assert reference.name == 'refs/tags/version1' API implementation options:
I think my current preferences are 2, 3, 1. |
hmm, though naming it |
Quick first-cut implementation of (1) with a separate |
At first I was confused about the word Well, looks good, except for the naming. The different After some thought I do like the other one, So, your commit answers both Q2 and Q3, and it looks like it's enough to implement checkout, but if you wish to implement annotated commits then go ahead 😉 Whether to provide a higher level api and be more aggressive than libgit2 (Q1), that requires more thought.. To summarise:
Maybe we can do these in different PRs so they don't get too big? |
"commitish" and "refish" are terms that appear in the git documentation, but they're not canonically defined anywhere as far as I can see 😄 I had to look up "dwim" too, wasn't particularly intuitive. But follows libgit2, and I'm all for computers doing what I mean.
I'll change the names and then see what AnnotatedCommit and/or a higher-level API might look like. Though I'm heading on paternity leave for a few weeks and chances of me getting to it before I disappear are virtually zero. |
Merged, thanks! And congratulations for the 👶 !! |
Trying to do a pygit2 equivalent of
git checkout
's refish resolving, and found libgit2'scheckout
example:It initially calls
resolve_refish()
which callsgit_reference_dwim()
which does a whole set of ref lookups (refs, heads, tags, branches, remotes, etc). That isn't available in pygit2 AFAICS. Returns an annotated commit, which seems to be a commit + the ref it was resolved from?then gets the actual commit, which is straightforward enough
then does the checkout
and finally updates HEAD using the annotated commit ref to decide whether the head is detached or not. This seems to be covered (a bit unintuitively) in pygit2 by passing a string vs oid to
repo.set_head()
So...
Q1: I wonder whether we should be preferring/helping get annotated commits when we're looking up references so the user can get back to their ref easily. We could be more aggressive about this than libgit2? eg: make AnnotatedCommit a subclass of Commit, and automatically use the underlying git_commit for APIs that need it.
Q2: Would adding support for
git_reference_dwim()
be a good idea? That returns references, so at least you could maintain a (reference, commit) pair in Python and doQ3: Would adding a
Repository.resolve_refish()
method (similarly torevparse_single()
) be useful? I thinkrevparse_single()
resolves all "commitish" properly?The text was updated successfully, but these errors were encountered: