Wikilink to Git `log:[reponame]@[branch]` resolves branch to its tip in href

[ethan.jucovy@…]

Using the wiki syntax log:rjollos.git@t10138 to link to a named branch log in a git repository results in a rendered link with an href like /log/rjollos.git/?rev=cd20d667b7b19e3ddba88bb2406472b71de797c2: the branch name "t10138" has been replaced with a reference to its current tip.

Using the unresolved branch name in the log reference would be preferable:

• It would allow users to bookmark the resulting link. Currently if a user bookmarks the resulting link, it will become "stale" as soon as the branch tip changes, and will no longer meet the user's expectation that it shows an up-to-date log of the t10138 branch.

• It would prevent "race conditions" which can cause the link to become stale. If a user visits a wiki page that contains the log: link, and then leaves that page open in a browser window, while another user commits and pushes changes to the t10138 branch, then the link will no longer point to the current branch tip without a page reload. If the user is very unlucky, the branch tip could even change during the lifecycle of the request to the wiki page, which means the link might even be stale right away.

This behavior is also inconsistent with browser:rjollos.git@t10138, which does result in a link to /browser/rjollos.git?rev=t10138 and therefore always points at the branch tip.

[ethan.jucovy@…]

This could be fixed by removing the call to normalize_rev in browser:trunk/trac/versioncontrol/web_ui/log.py#L403​ (no similar call is made in the browser.py's IWikiSyntaxProvider link resolving method)

Or possibly the git plugin's normalize_rev function at browser:trunk/tracopt/versioncontrol/git/git_fs.py#L412​ should be adjusted so that a provided rev is considered already normalized if it refers uniquely to a named branch or tag? The docstring for normalize_rev in trac.versioncontrol.api suggests this is allowed:

It's up to the backend to decide which string values of rev (usually provided by the user) should be accepted, and how they should be normalized. Some backends may for instance want to match against known tags or branch names.

But I'm not sure if that would have negative consequences elsewhere.

[Jun Omae]

Indeed. That is inconsistent between browser: and log: link.

trac/versioncontrol/web_ui/log.py

@@ -400 +400 @@
                                                   path or '/',
                                                   revs=str(revranges))
                     else:
-                        rev = repos.normalize_rev(revs)
+                        repos.normalize_rev(revs)  # verify revision
                         href = formatter.href.log(repos.reponame or None,
-                                                  path or '/', rev=rev)
+                                                  path or '/', rev=revs)
                     if query and '?' in href:
                         query = '&' + query[1:]
                     return tag.a(label, class_='source',

I try to add unit tests later.

[ethan.jucovy@…]

Looks like the MercurialPlugin has the same inconsistency: log:jomae.hg@t10313-hashed-path (href has resolved SHA) vs browser:jomae.hg@t10313-hashed-path (⇒ ?rev=10313-hashed-path) — I'll file that separately since it lives in its own repository.

[Jun Omae]

Looks like the MercurialPlugin has the same inconsistency: log:jomae.hg@t10313-hashed-path (href has resolved SHA) vs browser:jomae.hg@t10313-hashed-path (⇒ ?rev=10313-hashed-path)

I know. It doesn't depend on repository type. e.g. log:@0000001 and log:@head vs browser:@0000001 and browser:@head on svn. Therefore, we shouldn't change git or mercurial components.

[ethan.jucovy@…]

Replying to jomae:

Looks like the MercurialPlugin has the same inconsistency: log:jomae.hg@t10313-hashed-path (href has resolved SHA) vs browser:jomae.hg@t10313-hashed-path (⇒ ?rev=10313-hashed-path)

I know. It doesn't depend on repository type. e.g. log:@0000001 and log:@head vs browser:@0000001 and browser:@head on svn. Therefore, we shouldn't change git or mercurial components.

Oh — right — whoops, sorry about that.

[Jun Omae]

Also the log page doesn't work with named revision ranges, e.g. /log/?revs=12445-head which currently revs parameter is ignored and shows latest 100 revisions.

Proposed changes can be found in log:jomae.git:t11438.

[Jun Omae]

Committed in [12462] and merged to trunk in [12463].