IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
* Replace linkRegex with xurls library
Rather than maintaining a complicated regex to match URLs for
autolinking, gitea can use this existing go library that takes care of
the matching with very little code change to gitea itself. After
spending a while trying to find the perfect regex for all cases this library
still works better as it is more flexible than a single regex ever will be.
This will also fix the following issues: #5844#3095#3381
This passes all our current tests and I've added new ones mentioned in
those issues as well.
* Use xurls.StrictMatchingScheme instead of xurls.Strict
This is much faster and we only care about https? links to preserve
existing behavior.
The visitLinksForShortLinks feature would look inside of an <a> tag and
run shortLinkProcessorFull on any text, which attempts to create links
out of potential 'short links' like [[test]] [[link|example]] etc...
This makes no sense because you can't have nested links within an <a>
tag. Specifically, the html5 standard says <a> tags can't include
interactive content if they contain the href attribute:
http://w3c.github.io/html/single-page.html#the-a-element
And also defines an <a> element with a href attribute as interactive:
http://w3c.github.io/html/single-page.html#interactive-content
Therefore you can't really put a link inside of another link. In
practice none of this works anyways since browsers won't render it, it
would probably be broken if they tried, and it is causing a bug
(#4946). No current tests rely on this behavior either.
This removes the feature and also explicitly excludes the
current visitNodeForShortLinks from looking in <a> tags.
In #6211, we started creating repo_redirects for ownership transfers,
however that opens an edge case where a user might perform the
following sequence:
rename org1/repo1 -> org1/repo2 (creates org1/repo1 redirect)
transfer org2/repo1 -> org1/repo1 (org1/repo1 redirect continues to exist)
rename org1/repo1 -> org1/repo3 (fails due to existing org1/repo1 redirect)
This change ensures that each time we rename or transfer a repo,
we delete any existing redirects at the target location. This
already happens when a new repo is created. By doing this we ensure
that we'll never have both a repo and a redirect at the same location.
Signed-off-by: James E. Blair <jeblair@redhat.com>
Modify the current linkRegex to require http|https which appears to be
the intended behavior based on the comments. Right now, it also matches
anything starting with www as well. Also add testing for linkRegex
When transferring ownership of a repo to a different user/org,
create a repo redirect that points to the new location in the same
way that is done when a repo is renamed.
Signed-off-by: James E. Blair <jeblair@redhat.com>
