This repository has been archived by the owner on Sep 9, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1k
Gracefully handle abbreviated revisions during import #987
Labels
Comments
yeah, we'll definitely need some new plumbing. i think trying to work it in via |
5 tasks
I've spoken with @carolynvs about this and she says I can give it a try. |
I bequeath upon ye the sacride golden star of approval ⭐️ |
😟 Hope I didn't cut the line by submitting #1027 to fix this issue. Sorry for not checking in here first! |
I think we all realized before much work was done. Since we can't easily assign issues in GH, it's a distributed game of Hungry Hungry Hippos. 😝 Sorry @markwest1! |
No problem! I'm sure there's more work out there for me! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
dep
in general frowns on / doesn't support abbreviated revisions. However during import, and when reading external config on-the-fly, dep shouldn't just give up. Instead we should lookup the full revision for the short revision, and use the full revision in the imported lock, etc.I'm hoping that we can handle this in
SourceMgr.InferConstraint
, so that all the importers get this for "free", though we probably need plumbing in gps to do the dirty work.Notes:
SourceMgr.RevisionPresentIn
to check if the revision is valid, and for the git implementation the underlying command used actually prints the full revision, but nothing exists right now to bubble that up.InferConstraint
doesn't actually hit the repository to figure out if a rev is valid, it just matches a pattern. Since we actually validate tags/branches, it may be time to retire the guesswork, like doing length checks, and just reply on the source manager entirely to check if a string is a valid revision (and get the full revision if it was abbreviated).The text was updated successfully, but these errors were encountered: