| Submitter | via Mercurial-devel |
|---|---|
| Date | May 28, 2017, 6:15 a.m. |
| Message ID | <a0434758fd9a95ea3807.1495952130@martinvonz.svl.corp.google.com> |
| Download | mbox | patch |
| Permalink | /patch/20967/ |
| State | Changes Requested |
| Headers | show |
Comments
On 05/28/2017 08:15 AM, Martin von Zweigbergk wrote: > # HG changeset patch > # User Martin von Zweigbergk <martinvonz@google.com> > # Date 1495944531 25200 > # Sat May 27 21:08:51 2017 -0700 > # Node ID a0434758fd9a95ea3807ff4766eaedff6852c628 > # Parent 36e6d5d9737962c3a1ec1eef1ef5ebb0a374ffd5 > hidden: rename "revealedrevs" to "anchorrevs" > > E.g. tags and bookmarks can reveal revisions that would otherwise be > hidden. A revision can also be revealed because one if its descendants > is visible. Let's use the term "anchors" for the former case > (bookmarks etc.). Note: With French as my primary language, "anchor" is less clear to me than blockers. However I trust native speaker to choose the right terms here. Cheers,
On May 29, 2017 8:46 AM, "Pierre-Yves David" <pierre-yves.david@ens-lyon.org> wrote: On 05/28/2017 08:15 AM, Martin von Zweigbergk wrote: > # HG changeset patch > # User Martin von Zweigbergk <martinvonz@google.com> > # Date 1495944531 25200 > # Sat May 27 21:08:51 2017 -0700 > # Node ID a0434758fd9a95ea3807ff4766eaedff6852c628 > # Parent 36e6d5d9737962c3a1ec1eef1ef5ebb0a374ffd5 > hidden: rename "revealedrevs" to "anchorrevs" > > E.g. tags and bookmarks can reveal revisions that would otherwise be > hidden. A revision can also be revealed because one if its descendants > is visible. Let's use the term "anchors" for the former case > (bookmarks etc.). > Note: With French as my primary language, "anchor" is less clear to me than blockers. However I trust native speaker to choose the right terms here. "pinned revs" might also have worked. Anchor makes it clearer that they're also holding up other revs (their ancestors), but that is also true for other visible revs, so in a way "pinned" may be more accurate. What do you (all) think? Cheers,
On 05/29/2017 06:21 PM, Martin von Zweigbergk wrote: > > > On May 29, 2017 8:46 AM, "Pierre-Yves David" > <pierre-yves.david@ens-lyon.org <mailto:pierre-yves.david@ens-lyon.org>> > wrote: > > On 05/28/2017 08:15 AM, Martin von Zweigbergk wrote: > > # HG changeset patch > # User Martin von Zweigbergk <martinvonz@google.com > <mailto:martinvonz@google.com>> > # Date 1495944531 25200 > # Sat May 27 21:08:51 2017 -0700 > # Node ID a0434758fd9a95ea3807ff4766eaedff6852c628 > # Parent 36e6d5d9737962c3a1ec1eef1ef5ebb0a374ffd5 > hidden: rename "revealedrevs" to "anchorrevs" > > E.g. tags and bookmarks can reveal revisions that would otherwise be > hidden. A revision can also be revealed because one if its > descendants > is visible. Let's use the term "anchors" for the former case > (bookmarks etc.). > > > Note: With French as my primary language, "anchor" is less clear to > me than blockers. However I trust native speaker to choose the right > terms here. > > > "pinned revs" might also have worked. Anchor makes it clearer that > they're also holding up other revs (their ancestors), but that is also > true for other visible revs, so in a way "pinned" may be more accurate. > What do you (all) think? I like pinned better (thank!) Cheers,
On Mon, May 29, 2017 at 12:41 PM, Pierre-Yves David <pierre-yves.david@ens-lyon.org> wrote: > > > On 05/29/2017 06:21 PM, Martin von Zweigbergk wrote: >> >> >> >> On May 29, 2017 8:46 AM, "Pierre-Yves David" >> <pierre-yves.david@ens-lyon.org <mailto:pierre-yves.david@ens-lyon.org>> >> wrote: >> >> On 05/28/2017 08:15 AM, Martin von Zweigbergk wrote: >> >> # HG changeset patch >> # User Martin von Zweigbergk <martinvonz@google.com >> <mailto:martinvonz@google.com>> >> # Date 1495944531 25200 >> # Sat May 27 21:08:51 2017 -0700 >> # Node ID a0434758fd9a95ea3807ff4766eaedff6852c628 >> # Parent 36e6d5d9737962c3a1ec1eef1ef5ebb0a374ffd5 >> hidden: rename "revealedrevs" to "anchorrevs" >> >> E.g. tags and bookmarks can reveal revisions that would otherwise >> be >> hidden. A revision can also be revealed because one if its >> descendants >> is visible. Let's use the term "anchors" for the former case >> (bookmarks etc.). >> >> >> Note: With French as my primary language, "anchor" is less clear to >> me than blockers. However I trust native speaker to choose the right >> terms here. >> >> >> "pinned revs" might also have worked. Anchor makes it clearer that >> they're also holding up other revs (their ancestors), but that is also >> true for other visible revs, so in a way "pinned" may be more accurate. >> What do you (all) think? > > > I like pinned better (thank!) I might go with "pinning" rather than "pinned", that is: pinning revs: the ones that force otherwise-hidden revisions to be visible pinned revs: revisions which would otherwise be hidden but are visible Not sure if that is a useful thought. > > Cheers, > > -- > Pierre-Yves David
On Tue, May 30, 2017 at 5:57 AM, Augie Fackler <raf@durin42.com> wrote: > On Mon, May 29, 2017 at 12:41 PM, Pierre-Yves David > <pierre-yves.david@ens-lyon.org> wrote: >> >> >> On 05/29/2017 06:21 PM, Martin von Zweigbergk wrote: >>> >>> >>> >>> On May 29, 2017 8:46 AM, "Pierre-Yves David" >>> <pierre-yves.david@ens-lyon.org <mailto:pierre-yves.david@ens-lyon.org>> >>> wrote: >>> >>> On 05/28/2017 08:15 AM, Martin von Zweigbergk wrote: >>> >>> # HG changeset patch >>> # User Martin von Zweigbergk <martinvonz@google.com >>> <mailto:martinvonz@google.com>> >>> # Date 1495944531 25200 >>> # Sat May 27 21:08:51 2017 -0700 >>> # Node ID a0434758fd9a95ea3807ff4766eaedff6852c628 >>> # Parent 36e6d5d9737962c3a1ec1eef1ef5ebb0a374ffd5 >>> hidden: rename "revealedrevs" to "anchorrevs" >>> >>> E.g. tags and bookmarks can reveal revisions that would otherwise >>> be >>> hidden. A revision can also be revealed because one if its >>> descendants >>> is visible. Let's use the term "anchors" for the former case >>> (bookmarks etc.). >>> >>> >>> Note: With French as my primary language, "anchor" is less clear to >>> me than blockers. However I trust native speaker to choose the right >>> terms here. >>> >>> >>> "pinned revs" might also have worked. Anchor makes it clearer that >>> they're also holding up other revs (their ancestors), but that is also >>> true for other visible revs, so in a way "pinned" may be more accurate. >>> What do you (all) think? >> >> >> I like pinned better (thank!) > > I might go with "pinning" rather than "pinned", that is: > > pinning revs: the ones that force otherwise-hidden revisions to be visible > pinned revs: revisions which would otherwise be hidden but are visible I was actually arguing that the "forces other hidden revisions to become visible" aspect should not be part of it. Consider this graph: o E | x D | | x C bookmark1 | | | x B |/ o A I would call C a pinned rev because it has the bookmark pointing to it. But also note that B and D are both revealed, the former because of C and the latter because of E. The point is that B is not (directly) revealed because of the bookmark, but because C is visible. It's subtle, but do you agree about the point? So these revisions are just overriding what hideablerevs() says should be hidden. That also makes me realize that we can simplify even further. The initial set of hidden nodes, before revealing ancestors, is simply "hideablerevs() - pinnedrevs()". More patches coming up :-) > > Not sure if that is a useful thought. > >> >> Cheers, >> >> -- >> Pierre-Yves David
On Tue, May 30, 2017 at 12:26 PM, Martin von Zweigbergk <martinvonz@google.com> wrote: > o E > | > x D > | > | x C bookmark1 > | | > | x B > |/ > o A > > I would call C a pinned rev because it has the bookmark pointing to > it. But also note that B and D are both revealed, the former because > of C and the latter because of E. The point is that B is not > (directly) revealed because of the bookmark, but because C is visible. > It's subtle, but do you agree about the point? Yeah, that makes sense. > So these revisions are > just overriding what hideablerevs() says should be hidden. > > That also makes me realize that we can simplify even further. The > initial set of hidden nodes, before revealing ancestors, is simply > "hideablerevs() - pinnedrevs()". More patches coming up :-) Nice. > >> >> Not sure if that is a useful thought. >> >>> >>> Cheers, >>> >>> -- >>> Pierre-Yves David
On 05/30/2017 06:26 PM, Martin von Zweigbergk wrote: > On Tue, May 30, 2017 at 5:57 AM, Augie Fackler <raf@durin42.com> wrote: >> On Mon, May 29, 2017 at 12:41 PM, Pierre-Yves David >> <pierre-yves.david@ens-lyon.org> wrote: >>> >>> >>> On 05/29/2017 06:21 PM, Martin von Zweigbergk wrote: >>>> >>>> >>>> >>>> On May 29, 2017 8:46 AM, "Pierre-Yves David" >>>> <pierre-yves.david@ens-lyon.org <mailto:pierre-yves.david@ens-lyon.org>> >>>> wrote: >>>> >>>> On 05/28/2017 08:15 AM, Martin von Zweigbergk wrote: >>>> >>>> # HG changeset patch >>>> # User Martin von Zweigbergk <martinvonz@google.com >>>> <mailto:martinvonz@google.com>> >>>> # Date 1495944531 25200 >>>> # Sat May 27 21:08:51 2017 -0700 >>>> # Node ID a0434758fd9a95ea3807ff4766eaedff6852c628 >>>> # Parent 36e6d5d9737962c3a1ec1eef1ef5ebb0a374ffd5 >>>> hidden: rename "revealedrevs" to "anchorrevs" >>>> >>>> E.g. tags and bookmarks can reveal revisions that would otherwise >>>> be >>>> hidden. A revision can also be revealed because one if its >>>> descendants >>>> is visible. Let's use the term "anchors" for the former case >>>> (bookmarks etc.). >>>> >>>> >>>> Note: With French as my primary language, "anchor" is less clear to >>>> me than blockers. However I trust native speaker to choose the right >>>> terms here. >>>> >>>> >>>> "pinned revs" might also have worked. Anchor makes it clearer that >>>> they're also holding up other revs (their ancestors), but that is also >>>> true for other visible revs, so in a way "pinned" may be more accurate. >>>> What do you (all) think? >>> >>> >>> I like pinned better (thank!) >> >> I might go with "pinning" rather than "pinned", that is: >> >> pinning revs: the ones that force otherwise-hidden revisions to be visible >> pinned revs: revisions which would otherwise be hidden but are visible > > I was actually arguing that the "forces other hidden revisions to > become visible" aspect should not be part of it. Consider this graph: > > o E > | > x D > | > | x C bookmark1 > | | > | x B > |/ > o A > > I would call C a pinned rev because it has the bookmark pointing to > it. But also note that B and D are both revealed, the former because > of C and the latter because of E. The point is that B is not > (directly) revealed because of the bookmark, but because C is visible. > It's subtle, but do you agree about the point? So these revisions are > just overriding what hideablerevs() says should be hidden. > > That also makes me realize that we can simplify even further. The > initial set of hidden nodes, before revealing ancestors, is simply > "hideablerevs() - pinnedrevs()". More patches coming up :-) That seems like a good idea. Cheers,
Patch
diff --git a/hgext/rebase.py b/hgext/rebase.py --- a/hgext/rebase.py +++ b/hgext/rebase.py @@ -1537,4 +1537,4 @@ cmdutil.afterresolvedstates.append( ['rebasestate', _('hg rebase --continue')]) # ensure rebased rev are not hidden - extensions.wrapfunction(repoview, 'revealedrevs', _rebasedvisible) + extensions.wrapfunction(repoview, 'anchorrevs', _rebasedvisible) diff --git a/mercurial/repoview.py b/mercurial/repoview.py --- a/mercurial/repoview.py +++ b/mercurial/repoview.py @@ -28,21 +28,21 @@ lead to crashes.""" return obsolete.getrevs(repo, 'obsolete') -def revealedrevs(repo): +def anchorrevs(repo): """revisions blocking hidden changesets from being filtered """ cl = repo.changelog - blockers = set() - blockers.update([par.rev() for par in repo[None].parents()]) - blockers.update([cl.rev(bm) for bm in repo._bookmarks.values()]) + anchors = set() + anchors.update([par.rev() for par in repo[None].parents()]) + anchors.update([cl.rev(bm) for bm in repo._bookmarks.values()]) tags = {} tagsmod.readlocaltags(repo.ui, repo, tags, {}) if tags: rev, nodemap = cl.rev, cl.nodemap - blockers.update(rev(t[0]) for t in tags.values() if t[0] in nodemap) - return blockers + anchors.update(rev(t[0]) for t in tags.values() if t[0] in nodemap) + return anchors def _consistencyblocker(pfunc, hideable, domain): """return non-hideable changeset blocking hideable one @@ -112,7 +112,7 @@ # check if we have wd parents, bookmarks or tags pointing to hidden # changesets and remove those. - blockers |= (hidden & revealedrevs(repo)) + blockers |= (hidden & anchorrevs(repo)) if blockers: hidden = hidden - _domainancestors(pfunc, blockers, mutable) return frozenset(hidden)