[PATCH] localrepo: abort commit if a subrepo is modified and ui.commitsubs=no

[Patrick Mézard]

Le 12/02/11 18:13, timeless a écrit :
> i know people like abort early, but i'd like to suggest that abort
> with all details is better.
> 
> if i have 3 subrepos and 2 are modified, i'd rather be told:
> 
> x subrepo has modifications
> y subrepo has modifications
> aborting due to dirty subrepos
> 
> otherwise, i try to commit (possibly writing a long message in
> notepad), get an error, fix the subrepo, try to recommit, and get
> another error.

I was tempted to do that at first, but stopped because that's not hg usual behaviour. For instance when you try to merge with uncommitted changes you get:

   abort: outstanding uncommitted changes (use 'hg status' to list changes)

Then you run "hg status" and do what you have to do.

The problem here is you cannot list the modified subrepos. With hg subrepos you can run "hg status --subrepos" but there is no support for other types of subrepos. In fact, one of the reasons for the current patch is I was previously running "hg summary" to detect unwanted changes to subrepos (I usually know when I update them so I can tell a modified one from a updated one), and was told there was one subrepo modified among four. This was really frustrating.

So I would prefer to fix this instead. We can implement "status --subrepos" for other kinds of subrepos but I am not sure Matt was really happy about it as you probably cannot revert stuff in these subrepos, etc... It also raises the issue that "hg status" cannot tell me if a subrepo was updated. Sure I can run "hg summary" but honestly I don't care about anything "hg summary" tells me except the subrepos bits I cannot get elsewhere. In fact, I am tempted to write an extension just to extend status output with this information.

--
Patrick Mézard