[PATCH 1 of 2] cat: record the current behavior of wildcard matches in subrepos

Kevin Bullock kbullock+mercurial at ringworld.org
Thu Dec 7 12:54:00 EST 2017


> On Dec 7, 2017, at 07:43, Yuya Nishihara <yuya at tcha.org> wrote:
> 
> On Wed, 6 Dec 2017 11:26:13 -0600, Kevin Bullock wrote:
>>> On Dec 4, 2017, at 08:47, Yuya Nishihara <yuya at tcha.org> wrote:
>>> 
>>> On Sun, 03 Dec 2017 12:55:36 -0500, Matt Harbison wrote:
>>> 
>>>> This is as good a place as any to ask- when do we follow through on the  
>>>> Subrepo Grand Plan? [1]  It seems that the long term plan was to always  
>>>> recurse by default, and this -S stuff was a bandaid for issues resolved  
>>>> long ago.  I wouldn't do it this cycle, given that we are have way  
>>>> through.  There are probably a few things that might need fixing first.   
>>>> (I'm thinking `hg serve --web-conf` doesn't know how to recurse, and I'm  
>>>> sure there are a couple of other odd cases.)  Maybe we will want an  
>>>> experimental flag to ease into it.
>>>> 
>>>> [1]  
>>>> https://www.mercurial-scm.org/pipermail/mercurial-devel/2011-October/034816.html
>>> 
>>> The grand plan sounds like a big BC since we have 6-year history of the current
>>> subrepo behavior.
>> 
>> I don't immediately see anything in that grand plan that breaks compatibility in any way that matters. It would be awfully nice to finally finish integrating subrepos into the UI.
> 
> I think "make hg <x> recurse subrepos by default" is a noticeable BC since
> we'll have to specify --no-subrepo to get files in the root repository, for
> example.

We wouldn't need to grow a flag for that, a fileset could do it: `hg status -X 'set:insubrepo()'`

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock



More information about the Mercurial-devel mailing list