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

[Kevin Bullock]

On 14 Feb 2011, at 8:02 PM, Mads Kiilerich wrote:

> Kevin Bullock wrote, On 02/14/2011 08:31 PM:
>> On Feb 14, 2011, at 9:34 AM, Mads Kiilerich wrote:
>>> The way I see it it is a fundamental property of all subrepos that they belong to one of these categories, and the sane value of "commitsubrepos" follows from that.
>> But in either case, you're still talking about workflow policy, not the fundamental nature of subrepos.
> 
> I think it makes a fundamental difference if a subrepo is a "just forget we are using subrepos" or a "this subrepo contains shared code that also is used in other contexts" subrepo.
> 
>> If there were really such different technical requirements, there should be two distinctly-handled types of subrepos (say 'modules' and 'externals' or somesuch distinction).
> 
> Yes, the same could be achieved by introducing another hg-based subrepo type. But I think these two basic usage scenarios for subrepos have so much in common that it is better to continue to consider it the same.

...which is exactly my point. Making such a strong distinction is confusing when there's only one fundamental type of subrepo. As I said, I don't think such a strong distinction is warranted, and it further runs the risk of unnecessarily limiting the utility of subrepos to these two particular models.

>> I think it would be confusing and frustrating to more users to embed this toggle into .hgsub than in a config setting (particularly if said config setting was commitsubrepos=False by default).
> 
> Why do you think that? Do you have some good use cases where some users are free to commit recursively without considering the subrepo structure, while other users consider the structure and carefully creates commit messages that reflects what actually is changed in the commit?


I can easily see cases where the desired usage would vary not just from user to user, but from commit to commit. Maybe you have a large web application structured as a bunch of plugins, so that functionality you write for one site can be reused in another. As you're developing one feature of the main app you're also developing a plugin's functionality, so you want to do recursive commits. But later, when that plugin is solid and being used in several projects, or once the main app is mature, you'd rather it _not_ do recursive commits. If it's a config setting, you can change it per-repo.

Or say you're doing code review for your colleague who's developing said web application. She wants recursive commits, but you're just doing some cleanup and so want to limit your commits to the particular subrepo. The two of you want a different setting for that knob.

For me the fundamental issue is still this: the way I make the warrant that a commit means is my own business, not the subrepo's. Mercurial tends to shy away from building policy into the structure of a repository—it prefers to provide certain provable guarantees, and leave policy to humans—and I don't see why this should be an exception.

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock