Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 15:48:24 +0200] rev 26792
applybundle: set 'bundle2=1' env for all transaction
This should be set for all bundle2 application, we enforce that at a low level.
This is for courtesy with hooks.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 15:47:20 +0200] rev 26791
unbundle: use 'bundle2.applybundle'
This is one such place.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 15:45:39 +0200] rev 26790
bundle2: introduce an "applybundle" function
There is a case where the intent is clear and the transaction is not optional. We
want to be able to alter that transaction in a wide and easy way. We cannot get
a unified '.apply(repo)' method for bundle1 and bundle2 yet because the api are
still a bit too far apart. But this is a good step forward to get the rc out.
Siddharth Agarwal <sid0@fb.com> [Thu, 15 Oct 2015 01:31:04 -0700] rev 26789
commands.resolve: conclude merge driver if no unresolved files are left
This can happen when either 'hg resolve --all' is called or a driver-resolved
file is explicitly requested.
This is done as part of 'hg resolve --all' so that users still have a chance to
test their changes before committing them.
The exact semantics here are still to be decided. This does not impact any
non-experimental features.
Thanks to Pierre-Yves David for some advice about this behavior in particular,
and merge drivers in general.
Siddharth Agarwal <sid0@fb.com> [Thu, 15 Oct 2015 01:27:06 -0700] rev 26788
commands.resolve: call driverpreprocess if we haven't run it yet
We need to be careful about allowing --mark and --unmark to keep working -- we
don't want the user to be stuck in a weird state. The exact behavior here is
still to be decided, though.
Siddharth Agarwal <sid0@fb.com> [Thu, 15 Oct 2015 01:22:01 -0700] rev 26787
merge.applyupdates: call driverconclude after performing merge actions
This will be a chance for the merge driver to finish resolving or generating
any driver-resolved files.
As before, having a separate error state from 'unresolved' is too big a
refactoring for now, so we hack around it by setting unresolved to a positive
value when necessary.
Siddharth Agarwal <sid0@fb.com> [Thu, 15 Oct 2015 01:19:10 -0700] rev 26786
merge.applyupdates: call driverpreprocess before starting merge actions
We also need to update our internal state to whatever state driverpreprocess
leaves it in.
Adding an error state separate from the unresolved count is too big a
refactoring for now, so we hack around it by setting it to a positive value to
indicate an error state.
Siddharth Agarwal <sid0@fb.com> [Thu, 15 Oct 2015 01:17:29 -0700] rev 26785
merge: add stubs for preprocess and conclude steps of merge driver
The exact semantics for what should happen (particularly with respect to error
handling) are still a bit hard to pin down, so I think it's better to
experiment with it as an extension for now. For now this stub will act as a
convenient point for extensions to hook on.
Siddharth Agarwal <sid0@fb.com> [Thu, 15 Oct 2015 01:15:22 -0700] rev 26784
commands.resolve: don't allow users to mark or unmark driver-resolved files
Users will often be in the habit of running 'hg resolve --mark --all' after
resolving merge conflicts in source files. We need to make sure this doesn't
cause driver-resolved files to be marked.
'hg resolve --all' will resolve driver-resolved files, though.
The weird conditional structure is to accommodate an upcoming patch.
Siddharth Agarwal <sid0@fb.com> [Thu, 15 Oct 2015 01:11:50 -0700] rev 26783
resolve: only create wctx once
This allows for status and other results on the wctx to be cached between iterations.