split: close transaction in the unlikely event of a conflict while rebasing
`hg split` *should* never result in conflicts, but in case there are
bugs, we should at least commit the transaction so they can continue
the rebase. One of our users ran into the regression fixed by
D10120. They fixed the conflict and the tried to continue the rebase,
but it failed with "abort: cannot continue inconsistent rebase"
because the rebase state referred to commits written in a transaction
that was never committed.
Side note: `hg split` should probably turn off copy tracing to reduce
the impact of such bugs, and to speed it up as well. Copies made in
the rebased commits should still be respected because `hg rebase`
calls `copies.graftcopies()`.
Differential Revision: https://phab.mercurial-scm.org/D10164
Address commentary in manifest.excludedmanifestrevlog.add -
specifically we should improve the collaboration with core so that
add() never gets called on an excluded directory and we can improve
the stand-in to raise a ProgrammingError.
Reason more completely about rename-filtering logic in
narrowfilelog. There could be some surprises lurking there.
Formally document the narrowspec format. For bonus points, unify with the
server-specified narrowspec format.
narrowrepo.setnarrowpats() or narrowspec.save() need to make sure
they're holding the wlock.
The follinwg places do an unrestricted dirstate walk (including files outside the
narrowspec). Some of them should perhaps not do that.
* debugfileset
* perfwalk
* sparse (but restricted to sparse config)
* largefiles