#596073 include information about which tags precede or follow a commit like gitk

Package:
gitweb
Source:
git
Submitter:
martin f krafft
Date:
2010-09-09 07:42:09 UTC
Severity:
wishlist
#596073#5
Date:
2010-09-08 14:09:25 UTC
From:
To:
It would be nice if gitweb's commit information (a=commit, and
possible a=commitdiff) included the same information gitk offers,
specicially which branches the commit is on, which tags it follows,
and which it precedes.
#596073#10
Date:
2010-09-08 23:21:44 UTC
From:
To:
I worry that this information is rather expensive to generate, especially
for a large repository like git.git or linux-2.6.git.  gitk tries to solve
that problem by writing a cache into the repository directory, but gitweb
might not have write access.  Also, even with the cache gitk must consume
a lot of memory to read all the information in.  (I find gitk unusable
unless I turn these features off.)

So, if this is implemented, it will almost certainly have to be off by
default.

Anders
#596073#15
Date:
2010-09-09 05:08:09 UTC
From:
To:
also sprach Anders Kaseorg <andersk@MIT.EDU> [2010.09.09.0121 +0200]:
to) generate this information up front for all commits, while gitweb
only needs to generate it for a single commit at a time. So the
question is really: are the required calls to git-describe and/or
git-name-rev that expensive?

Sure thing.
#596073#20
Date:
2010-09-09 07:40:01 UTC
From:
To:
Unfortunately, they can be.  For example, on my (admittedly rather huge)
linux-2.6 repository with a cold cache, then again with a warm cache:

$ time git name-rev 0af184bb9f80edfbb94de46cb52e9592e5a547b0
0af184bb9f80edfbb94de46cb52e9592e5a547b0 tags/v2.6.17.4~1

real	1m12.334s
user	0m16.510s
sys	0m1.440s
$ time git name-rev 0af184bb9f80edfbb94de46cb52e9592e5a547b0
0af184bb9f80edfbb94de46cb52e9592e5a547b0 tags/v2.6.17.4~1

real	0m13.305s
user	0m12.720s
sys	0m0.580s

Basically, this is slow because it needs to walk up through the entire
repository from every ref through parent pointers looking for the given
commit.  Reading the entire graph structure into a cache (like gitk) can
make this more efficient on average if you do a lot of queries in a row,
but otherwise there isn’t much you can do given the current Git repository
format.

Anders