Edgewall Software
Modify

Opened 7 years ago

Closed 7 years ago

#11438 closed defect (fixed)

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

Reported by: ethan.jucovy@… Owned by: Jun Omae
Priority: normal Milestone: 1.0.2
Component: version control/log view Version: 1.0-stable
Severity: normal Keywords:
Cc: Branch:
Release Notes:

log: generates a link with named revisions which be consistent with browser: link and the log page works with named revision ranges on Subversion.

API Changes:
Internal Changes:

Description

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.

Attachments (0)

Change History (7)

comment:1 by ethan.jucovy@…, 7 years ago

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.

comment:2 by Jun Omae, 7 years ago

Milestone: next-stable-1.0.x
Owner: set to Jun Omae
Status: newassigned
Version: 1.0-stable

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

  • trac/versioncontrol/web_ui/log.py

    diff --git a/trac/versioncontrol/web_ui/log.py b/trac/versioncontrol/web_ui/log.py
    index 8898919..cb37fb0 100644
    a b class LogModule(Component):  
    400400                                                  path or '/',
    401401                                                  revs=str(revranges))
    402402                    else:
    403                         rev = repos.normalize_rev(revs)
     403                        repos.normalize_rev(revs)  # verify revision
    404404                        href = formatter.href.log(repos.reponame or None,
    405                                                   path or '/', rev=rev)
     405                                                  path or '/', rev=revs)
    406406                    if query and '?' in href:
    407407                        query = '&' + query[1:]
    408408                    return tag.a(label, class_='source',

I try to add unit tests later.

comment:3 by ethan.jucovy@…, 7 years ago

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.

in reply to:  3 ; comment:4 by Jun Omae, 7 years ago

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.

Last edited 7 years ago by Jun Omae (previous) (diff)

in reply to:  4 comment:5 by ethan.jucovy@…, 7 years ago

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.

comment:6 by Jun Omae, 7 years ago

Milestone: next-stable-1.0.x1.0.2

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.

comment:7 by Jun Omae, 7 years ago

Release Notes: modified (diff)
Resolution: fixed
Status: assignedclosed

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Jun Omae.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Jun Omae to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.