[PATCH 2 of 3] revert: rename working directory matcher 'm' -> 'wmatch'

Matt Harbison mharbison72 at gmail.com
Fri Mar 27 20:54:36 CDT 2015


On Fri, 27 Mar 2015 14:59:17 -0400, Jordi GutiƩrrez Hermoso  
<jordigh at octave.org> wrote:

> On Fri, 2015-03-27 at 13:15 -0500, Matt Mackall wrote:
>> On Thu, 2015-03-26 at 21:06 -0400, Matt Harbison wrote:
>
>> > 	 "Because revert does not change the working directory parents..."
> [snip]
>>
>> Oh man, that's a hard question. My internal model of subrepo semantics
>> says that yes, we should get a clean checkout of subrepos under the top
>> level, but I can believe that would surprise people. I'm not sure if the
>> alternative is particularly logically consistent though.
>
> I think the expected behaviour would be to propagate operations to
> subrepos? revert at the top level also reverts any unclean state in
> subrepos, and update at the top level also changes the revisions in
> subrepos.

That's my expectation as well- I can't think of any commands that support  
subrepos that aren't command propagation.  (Maybe update, but that's still  
update, possibly with a pull/clone if necessary).

For better or worse, I think of the support commands have for subrepos as  
basically shorthand for 'hg -R subrepo <cmd> [subrepo/path/to/file]'.  And  
that to me is nice, because the more commands support them directly, the  
more they fade into the background.

> It would be super-weird if revert at the top level translated into
> update in a subrepo. It's already weird enough that update ceases to
> be a local operation with subrepos.
>


More information about the Mercurial-devel mailing list