Link to previous blames in file blame page #16259
Labels
No Label
backport/done
backport/v1.0
backport/v1.1
backport/v1.10
backport/v1.11
backport/v1.12
backport/v1.13
backport/v1.14
backport/v1.15
backport/v1.2
backport/v1.3
backport/v1.4
backport/v1.5
backport/v1.6
backport/v1.7
backport/v1.8
backport/v1.9
bounty
changelog
dependencies
frontport/done
frontport/main
good first issue
Hacktoberfest
hacktoberfest-accepted
in progress
kind/api
kind/breaking
kind/bug
kind/build
kind/deployment
kind/deprecated
kind/docs
kind/enhancement
kind/feature
kind/lint
kind/misc
kind/moderation
kind/package
kind/proposal
kind/question
kind/refactor
kind/regression
kind/security
kind/summary
kind/testing
kind/translation
kind/ui
kind/upstream-related
kind/usability
kind/ux
lgtm/done
lgtm/need 1
lgtm/need 2
performance/bigrepo
performance/cpu
performance/memory
performance/speed
priority/critical
priority/low
priority/maybe
priority/medium
proposal/rejected
reviewed/confirmed
reviewed/duplicate
reviewed/fixed
reviewed/invalid
reviewed/not-a-bug
reviewed/wontfix
skip-changelog
stale
status/blocked
status/needs-feedback
status/wip
theme/2fa
theme/authentication
theme/avatar
theme/backup-restore
theme/docker
theme/federation
theme/issues
theme/kanban
theme/markdown
theme/migration
theme/mobile
theme/pr
theme/signing
theme/sqlite
theme/timetracker
theme/webhook
theme/wiki
No Milestone
No project
No Assignees
2 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: lunny/gitea#16259
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "previos-blame-link"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Adds a link to each blame hunk, to view the blame of an earlier version of the file, similar to GitHub. Also refactors the blame render from fmtstring based to template based.
This supersedes #15171: I copied that PR, resolved conflicts, and adressed my code review concerns, as the original author seems unresponsive.
old demo gif:
Fixes #15109
Closes #15171
@ -163,0 +174,4 @@
// find parent commit
if commit.ParentCount() > 0 {
psha := commit.Parents[0]
Argh!
commit.HasPreviousCommit is not free and is potentially computationally very expensive. It involves a call to
git merge-base --is-ancestor
. The results of this need to be cached at least within the loop.Further I don't think:
haz, _ := commit.HasPreviousCommit(previousCommit.ID)
can ever be false as it is a 0-level parent by line 182:previousCommit, err := commit.Parent(0)
.haz1, _ := previousCommit.HasFile(ctx.Repo.TreePath); haz1
- is also quite expensive and should be cached.@ -163,0 +174,4 @@
// find parent commit
if commit.ParentCount() > 0 {
psha := commit.Parents[0]
Oh ok.
Is there a common cache facility to use for this? Or should I just do an adhocmap[string]bool
cache?I assume you mean to implement something analog to
LastCommitCache
likeCommitHasPathCache
?@ -163,0 +174,4 @@
// find parent commit
if commit.ParentCount() > 0 {
psha := commit.Parents[0]
probably just use a just out-of-loop cache for the moment. In this case I don't think there's likely to be benefit pushing up to
modules/cache
or using an*lru.TwoQueue
/*lru.Cache
directly.We should consider whether to cache the results of the internal
git.Commit.GetFiles
in modules/cache.Cache but at present the default cache is unlimited unless we merge my PR.@ -163,0 +174,4 @@
// find parent commit
if commit.ParentCount() > 0 {
psha := commit.Parents[0]
@ -163,0 +174,4 @@
// find parent commit
if commit.ParentCount() > 0 {
psha := commit.Parents[0]
thanks, done