Opened 12 years ago
Closed 10 years ago
#11050 closed defect (fixed)
Hash changeset ids are not allowed in revision log
Reported by: | Owned by: | Jun Omae | |
---|---|---|---|
Priority: | high | Milestone: | 1.0.6 |
Component: | wiki system | Version: | 1.0.1 |
Severity: | normal | Keywords: | traclinks, changeset, revision, log, hg, git |
Cc: | Branch: | ||
Release Notes: |
Allow hash changeset ids and branch names in revision ranges, e.g. |
||
API Changes: | |||
Internal Changes: |
Description
According to TracLinks, the following markup styles are available for revision logs:
r1:3, [1:3] or log:@1:3, log:trunk@1:3, [2:5/trunk]
But I'm unable to use hash ids in either one of them. Let's try with cboos.git and its topmost changesets:
log:cboos.git@ec351621:f6b72a6a
(had to be quoted, otherwise aValueError
is raised);- [ec351621:f6b72a6a/cboos.git] (just unrecognized)
The same goes for Mercurial repos, but at least there are revnumbers, although they are of limited use due to their nature.
There are similar problems with default repository, but since here default repo is kept in SVN (what a shame!) I can't demonstrate it :)
Attachments (0)
Change History (15)
comment:1 by , 12 years ago
Milestone: | → next-stable-1.0.x |
---|
comment:2 by , 12 years ago
Priority: | normal → high |
---|
comment:3 by , 11 years ago
Keywords: | traclinks added; links removed |
---|
comment:4 by , 11 years ago
Milestone: | next-stable-1.0.x → 1.0.3 |
---|---|
Owner: | set to |
Status: | new → assigned |
Proposed changes can be found in log:jomae.git:t11050.
comment:5 by , 11 years ago
Keywords: | traclinks,changeset,revision,log,hg,git → traclinks, changeset, revision, log, hg, git |
---|
comment:7 by , 10 years ago
Seems to work well, and also helps with #11888.
I suspect in RevRanges.truncate
it should be:
-
trac/versioncontrol/web_ui/util.py
diff -r 01c646dbc14b -r 3b4fe9b8e444 trac/versioncontrol/web_ui/util.py
a b 292 292 break 293 293 pairs.append(p) 294 294 if pairs: 295 self.a = pairs[0][0]296 self.b = pairs[-1][1]295 ranges.a = pairs[0][0] 296 ranges.b = pairs[-1][1] 297 297 return ranges 298 298 299 299 def _reduce(self):
trac.versioncontrol.web_ui.util.RevRanges
is a generalization of trac.util.Ranges
that supports non-integer revisions, right? The comments from there help a lot.
RevRanges
doesn't seem to use the path
parameter, and only uses repos.normalize_rev
from repos
. Maybe it could become something like trac.util.GeneralRanges(r=[], normalize=int)
.
comment:8 by , 10 years ago
Milestone: | 1.0.3 → 1.0.4 |
---|
comment:9 by , 10 years ago
Milestone: | 1.0.4 → 1.0.5 |
---|
follow-up: 11 comment:10 by , 10 years ago
Milestone: | 1.0.5 → 1.0.6 |
---|
Retargeting. Revised changes can be found in jomae.git@t11050v2. However, that is still broken. https://github.com/libgit2/pygit2/compare/v0.21.3...v0.21.4 shows 35 commits but Trac shows 9 revisions for log:@v0.21.3:v0.21.4
.
follow-up: 12 comment:11 by , 10 years ago
Milestone: | 1.0.6 → 1.0.5 |
---|
Again.
Retargeting. Revised changes can be found in jomae.git@t11050v2. However, that is still broken. https://github.com/libgit2/pygit2/compare/v0.21.3...v0.21.4 shows 35 commits but Trac shows 9 revisions for
log:@v0.21.3:v0.21.4
.
That occurs when log view with revision ranges walks merge commits. When the log view with revision ranges, Node.get_history(limit=2)
is repeatedly called to retrieve next revision until the end of revision ranges.
A merge commit has usually two parent commits. However Node.get_history(limit=2)
returns only one of the parents….
We should create a new ticket for another issue, so I'll push proposed changes if no objections.
comment:12 by , 10 years ago
That occurs when log view with revision ranges walks merge commits. When the log view with revision ranges,
Node.get_history(limit=2)
is repeatedly called to retrieve next revision until the end of revision ranges. A merge commit has usually two parent commits. HoweverNode.get_history(limit=2)
returns only one of the parents….We should create a new ticket for another issue, so I'll push proposed changes if no objections.
That issue is fixed in [69ff00b96/jomae.git].
comment:13 by , 10 years ago
Milestone: | 1.0.5 → 1.0.6 |
---|
I found breakages in the proposed changes. More testing is needed. Retargeting to next stable.
comment:14 by , 10 years ago
Again and again. Proposed changes in log:jomae.git@t11050v3. I'll push it at start of milestone:1.0.6.
comment:15 by , 10 years ago
Release Notes: | modified (diff) |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
This one is worth a fix on 1.0-stable.
The rest also deserve to be supported in some future version, I agree.