subrepo wish list
Michael Ekstrand
michael at elehack.net
Wed Apr 14 20:42:53 CDT 2010
On 04/14/2010 08:31 PM, Steve Losh wrote:
> On Apr 14, 2010, at 9:27 PM, Michael Ekstrand wrote:
>
>> On 04/14/2010 08:09 PM, Steve Losh wrote:
>>> On Apr 14, 2010, at 6:18 PM, Michael Ekstrand wrote:
>>>
>>>> After working with subrepos in Mercurial for some weeks now, I
>>>> have been getting somewhat frustrated with the remaining user
>>>> experience holes in them. But with that, I also have proposals
>>>> for what would make this experience better.
>>>>
>>>> The purpose of this message is not to demand "write my feature!
>>>> fix my bug!", but rather to share my thoughts based on some
>>>> subrepos experience, see if there are already-existing methods
>>>> to achieve my goals, and start a conversation about how best to
>>>> fill these gaps.
>>>>
>>>> For subrepos to be near-perfect for me, two things are missing
>>>> or "broken": * Status support is nonexistent, as near as I can
>>>> tell * Commit recursively auto-committing doesn't fit well w/
>>>> my workflow
>>>>
>>>> For the first, it looks like there has already been some
>>>> discussion on doing this and some submitted patches. It seems
>>>> to me that there are 3 states a subrepo can be in: * Unchanged,
>>>> and thus suppressible from status display * Changed but
>>>> committed: the subrepo is changed from a parent repo
>>>> perspective, but itself has no uncommitted changes. * Possibly
>>>> changed and dirty: the subrepo has uncommitted changes, and its
>>>> last checked-in status may or may not be the same as recorded
>>>> in .hgsubstate.
>>>
>>> Personally I'd find the following two features helpful:
>>>
>>> * 'hg status --suprepos' would show *all* uncommitted changes,
>>> including any in subrepositories. Maybe an extra character could
>>> be added to the output to distinguish changes in subrepos from
>>> changes in the main repo, but that's not a huge deal.
>>
>> That's pretty much what I'm thinking of, with one addition: a line
>> showing the subrepo itself if it is changed and/or dirty. That
>> seems to be a useful piece of 'status'.
>
> The reason I wouldn't want to show that is because status is supposed
> to show *files*. The first sentence of 'hg help status' is:
>
> Show status of files in the repository.
>
> Showing whether a subrepo as a whole is dirty would be useful, but it
> seems like it would break the "do one thing and do it well"
> philosophy of Mercurial.
>
> I'm not sure where the best place to put the "which subrepos are
> dirty" output would be.
Hmm. I think of a subrepository as a "file" which happens to be a
repository. I know that isn't how they're implemented, but it's how I
think of them and try to work with them functionally, and I think it's a
rather clean way to do so. In that frame of mind, it makes sense to
display them in the status listing.
But perhaps there is another place. I had planned that, should such a
--subrepos option be added to status, I would make an 'rstatus' alias to
it; perhaps 'rstatus' could be a new command (via an extension?) to list
the status including changed subrepos.
- Michael
More information about the Mercurial
mailing list