adityasaky
commented
3 weeks ago On the first change, I briefly considered whether the RSL entry ought to also record the local branch name. I ultimately decided against this because it doesn't seem to have any value to anyone else performing verification as they don't actually see a branch with that name. IMO, the user's choice to have some other name is a detail we don't particularly care about, but I may be missing some scenarios where it does matter. From my own experience, this comes up when I branch off locally to try new things, debug CI failures and so on. So a cool-feature branch becomes cool-feature-debug-windows or something, and when I have a fix, I sometimes just push cool-feature-debug-windows:cool-feature.
@JustinCappos @wlynch thoughts?
Closes #413
This PR makes two changes. First, when recording an entry in the RSL, it supports the src ref name being different from the dst ref name. For example,
git push origin local-branch-name:remote-branch-nameupdatesremote-branch-nameon origin with the tip oflocal-branch-name. So, the RSL entry for this push must recordremote-branch-nameas the ref name updated, which is what everyone else sees, and uselocal-branch-nameas the target ID.Second, the verification workflow now accepts an optional
--remote-ref-nameflag. When this is set, the workflow uses the remote ref name to identify and verify the relevant RSL entries, but finally uses the local ref name to check that the tip matches. We need this for the following case:I debated whether the flag ought to be inverted, so we
gittuf verify-ref --local-ref-name=local-branch-name remote-branch-name. This makes more sense from the implementation PoV because we use the remote ref name a lot more with the RSL verification, but to me it appears to be counterintuitive to the user. They ought to be providing the refname they see in their copy of the repository, I think.