[Top][All Lists]

[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

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
   $ hg diff -r59951 -r59951^ | wc -l
   $ hg id -n -r59951^

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 
     (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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]