[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