* Add support for federated avatars
Fixes#3105
Removes avatar fetching duplication code
Adds an "Enable Federated Avatar" checkbox in user settings
(defaults to unchecked)
Moves avatar settings all in the same form, making
local and remote avatars mutually exclusive
Renames UploadAvatarForm to AvatarForm
as it's not anymore only for uploading
* Run gofmt on all modified files
* Move Avatar form in its own page
* Add go-libravatar dependency to vendor/ dir
Hopefully helps with accepting the contribution.
See also #3214
* Revert "Add go-libravatar dependency to vendor/ dir"
This reverts commit a8cb93ae640bbb90f7d25012fc257bda9fae9b82.
* Make federated avatar setting a global configuration
Removes the per-user setting
* Move avatar handling back to base tool, disable federated avatar in offline mode
* Format, handle error
* Properly set fallback host
* Use unsupported github.com mirror for importing go-libravatar
* Remove comment showing life exists outside of github.com
... pity, but contribution would not be accepted otherwise
* Use Combo for Get and Post methods over /avatar
* FEDERATED_AVATAR -> ENABLE_FEDERATED_AVATAR
* Fix persistance of federated avatar lookup checkbox at install time
* Federated Avatars -> Enable Federated Avatars
* Use len(string) == 0 instead of string == ""
* Move import line where it belong
See
https://github.com/Unknwon/go-code-convention/blob/master/en-US/import_packages.md
Pity the import url is still the unofficial one, but oh well...
* Save a line (and waste much more expensive time)
* Remove redundant parens
* Remove an empty line
* Remove empty lines
* Reorder lines to make diff smaller
* Remove another newline
Unknwon review got me start a fight against newlines
* Move DISABLE_GRAVATAR and ENABLE_FEDERATED_AVATAR after OFFLINE_MODE
On re-reading the diff I figured what Unknwon meant here:
https://github.com/gogits/gogs/pull/3320/files#r73741106
* Remove newlines that weren't there before my intervention
- Try to reduce memory allocations
- Add possibility to disable diff highlight (can improve performance for large diffs)
- Tweaking with cost for prettier (cleaner) diffs
- Do not calculate diff when the number of removed lines in a block is not equal to the number of added lines (this usually resulted in ugly diffs)
* Fix#3315: Release dont use tag creation date
* Simplify code and apply gofmt
* remove useless block (ctx.Repo.GitRepo.GetTag) on EditReleasePost
* apply gofmt on modified files
* Add API support for labels.
* Error handling for adding/replacing multiple issue labels
* Revisions to function names and error handling. Use issue.ClearLabels in replace/clear functions
* Additional code cleanup
* Add support for .diff and .patch
Add the ability to get text-diff and format-patch by adding .diff or
.patch in the end of a commit url. Issue #2641
* models: git_diff: various fixes
* Renames commitId to commitID.
* Writes stderr to a bytes.Buffer and displays proper error message on
command failure.
* Various style changes.
Signed-off-by: Dennis Chen <barracks510@gmail.com>
If anonymous (not signed in user) requests page
"/:owner/:repo/pulls" he gets an error:
template: repo/issue/list:11:105: executing "repo/issue/list" at <.PullRequestCtx.Base...>: nil pointer evaluating *models.Repository.Link
This commit fixes that.
Signed-off-by: Dmitry Yu Okunev <dyokunev@ut.mephi.ru>
Since the release struct is initialized with the current `HEAD` of the
current `release.Target` the commit id has to be updated if the tag
commit already exists. Otherwise the linked commit on the release page
will target the current `HEAD` at release time.
When calculating the current behind commit count the calculation should
use the current release target to get the total commit count. Should the
release target not exist anymore the calculation will return zero for
the newest release on that target. Older releases on that target will then
use that calculated commit count as reference.
The only use case that is now somehow invalid is when the release target
was merged / deleted after a tag on that release target:
master 1 - - - - - - - 6
\ /
branch 2 - 3 - 4 - 5
When `4` is the last tag on branch `branch` and the branch `branch` is not
yet deleted the calculated numbers would be:
1 commits to branch since this release
Now if the branch `branch` gets deleted the calculation function will not
find the branch and use the commit count of the newest release (`4`) as
reference resulting in:
0 commit to branch since this release
This fixes#3326
