Fix#20456
At some point during the 1.17 cycle abbreviated refs to issue branches
started breaking. This is likely due serious inconsistencies in our
management of refs throughout Gitea - which is a bug needing to be
addressed in a different PR. (Likely more than one)
We should try to use non-abbreviated refs as much as possible. That is
where a user has inputted a abbreviated ref we should add refs/heads/ if
it is branch etc. I know people keep writing and merging PRs that remove
prefixes from stored content but it is just wrong and it keeps causing
problems like this. We should only remove the prefix at the time of
presentation as the prefix is the only way of knowing umambiguously and
permanently if the ref is referring to a branch, tag or commit. We need
to make it so that every ref has the appropriate prefix, and probably
also need to come up with some definitely unambiguous way of storing
SHAs if they're used in a ref field. We must not store potentially
ambiguous refs. (Especially tagnames - there is no reason why users cannot
create a branch with the same short name as a tag and vice versa and any
attempt to prevent this will fail. You can even create a branch and a
tag that matches a SHA1 pattern.)
To that end in order to fix this bug, when parsing issue templates check
the provided Ref, if it does not start with refs/ add the BranchPrefix
to it. This allows people to make their templates refer to a tag.
Next we need to handle the issue links that are already written. The
links here are created with `git.RefURL`
Here we see there is a bug introduced in #17551 whereby the provided Ref
can be double-escaped so we remove the incorrect external escape.
(The escape added in #17551 is in the right place - unfortunately it
missed that the calling function was doing the wrong thing.)
Then within RefURL we check if the unprefixed ref could actually be a
SHA before defaulting that an unprefixed ref is actually a commit - if not
it is assumed to be a branch. This will handle most of the problem cases
excepting the very unusual cases where someone has deliberately written
a branch to look like a SHA1.
But please if something is called a `ref` or interpreted as a `ref` make
it a full-ref before storing or using it. By all means if something is a
`branch` assume the prefix is removed but always add it back in if you
are using it as a `ref`. Stop storing abbreviated branch names and tag
names as refs. It will keep on causing problems like this.
Fix#20456
Signed-off-by: Andrew Thornton <art27@cantab.net>
42d2b83950