[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22032: 24.3; VC doesn't handle hg hidden revisions
From: |
Dmitry Gutov |
Subject: |
bug#22032: 24.3; VC doesn't handle hg hidden revisions |
Date: |
Wed, 16 Dec 2015 02:03:14 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 |
On 12/16/2015 01:53 AM, Andy Moreton wrote:
This problem with revision IDs also accurs if the repo contains named
branches. in that case the numerically previous revision may be on a
different branch, resulting in a meaningless diff that is slow to
compute.
So it's a bug in the current implementation, even without hidden revisions?
I'll try to remember this next time someone tells me about
user-friendliness of numeric revisions. :)
For example (from a non-public repo with named branches), where rev
59951 and rev 59950 are on different named branches:
$ hg diff -r59951 -r59950 | wc -l
88188
$ hg diff -r59951 -r59951^ | wc -l
70
$ hg id -n -r59951^
59925
The first example diffs agaist the previous revision ID (which is on a
different branch), and produces large and useless diff output. The second
example diffs against the (first) parent, and is what is actually wanted.
If there's a direct counterpart to 'git rev-parse 59951^', it would be
handy here.
To also work with named branches, something like this (untested) would be
better:
(format "last(ancestors(%d) and not hidden())" newrev)
So, what if we don't pass "--hidden" to this command? Will `ancestors'
error out upon encountering a hidden revision, or will they skip to the
first visible one?
In the latter case, there's no need to check 'not hidden()', and the
compatibility problem can be solved like that.