I am about to send an updated version of this rebased on the current trunk. I can confirm the test now pass on current trunk.
Fri, Dec 3
I can confirm that his changeset is no longer necessary now that no longer try to record dirstate cache during hg commit.
- I agree that we should take the wlock in addition to the lock as we will be running an upgrade.
- the best way to get out of your trouble is to make the "new" peer (created after status) aware of the locking. Something like the logic below seems "suitable", Since this only happens in this specific cases, it seems like a bad idea to alter too much of the main peer API (we could still have a dedicated method on the repository for that)
The ability to use --no- variants is fairly new (a couple of year maybe ?), but I (and others) have been trying to put it to good use since then. Since is quite new I don't think they so many of of such flag yet, but a notable example of that approach is --merge that I use daily.
As in hg update --no-merge? I don't see how that does anything, I might be missing something?@command( b'update|up|checkout|co', [... (b'm', b'merge', None, _(b'merge uncommitted changes')), ...] ) def update(ui, repo, node=None, **opts): ... merge = opts.get('merge') ... if check: updatecheck = b'abort' elif merge: # Truthiness check only updatecheck = b'none'
The only way that might do something is if you have something in [defaults] that sets --merge to true, such that this overrides it.