verify locks against each ref being pushed#2706
Conversation
|
I ran into a snag supporting the locks/verify endpoint. Pushes can either specify a remote ref, or you can push all the refs. $ git push origin local-branch:remote-branch
# calls the pre-push hook by passing this to STDIN:
echo "refs/heads/local-branch AFTER-SHA refs/heads/remote-branch BEFORE-SHA" | git lfs pre-pushThat leaves us with some options:
I'm currently leaning towards option 2. |
|
#2700 implements this portion of the
Now, it needs to implement the following:
|
config/config.go
Outdated
| merge, _ := c.Git.Get(fmt.Sprintf("branch.%s.merge", r.Name)) | ||
| if strings.HasPrefix(merge, "refs/heads/") { | ||
| c.remoteRef = &git.Ref{ | ||
| Name: merge[11:], |
Since at least PR git-lfs#2706, and indeed earlier, the local and remote refs which are part of the RefUpdate structure have been referred to as the "left" and "right" refs, terminology which stems from the origin of this structure in the "git lfs pre-push" hook command, where each line of input contains commit information in the form: <local ref> <local sha1> <remote ref> <remote sha1> However, outside of this context, "left" and "right" are ambiguous terms, and may potentially be confused with the left and right refs specified in a Git-style two-dot range notation. We therefore replace these terms with "local" and "remote", which should help clarify their purpose throughout the codebase.
Since at least PR git-lfs#2706, and indeed earlier, the local and remote refs which are part of the RefUpdate structure have been referred to as the "left" and "right" refs, terminology which stems from the origin of this structure in the "git lfs pre-push" hook command, where each line of input contains commit information in the form: <local ref> <local sha1> <remote ref> <remote sha1> However, outside of this context, "left" and "right" are ambiguous terms, and may potentially be confused with the left and right refs specified in a Git-style two-dot range notation. We therefore replace these terms with "local" and "remote", which should help clarify their purpose throughout the codebase.
Since at least PR git-lfs#2706, and indeed earlier, the local and remote refs which are part of the RefUpdate structure have been referred to as the "left" and "right" refs, terminology which stems from the origin of this structure in the "git lfs pre-push" hook command, where each line of input contains commit information in the form: <local ref> <local sha1> <remote ref> <remote sha1> However, outside of this context, "left" and "right" are ambiguous terms, and may potentially be confused with the left and right refs specified in a Git-style two-dot range notation. We therefore replace these terms with "local" and "remote", which should help clarify their purpose throughout the codebase.
Implements 2 aspects of #2712:
push.defaultsupport, which governs how Git chooses an implicit remote ref based on the remote and local ref being pushed.Bonus: locks are not verified for
git lfs push --object-idanymore. Since this push doesn't affect any Git code, there's no need to verify anything.This also extracts a
*lockVerifierand*refUpdate. There is still too much coupling, but it's better than everything being in*uploadContext. Baby steps....