Siddharth Agarwal <sid0@fb.com> [Sun, 15 Nov 2015 21:55:46 -0800] rev 27087
merge.recordupdates: don't require action keys to be present in dict
We're going to use this function for a much smaller set of actions in the next
patch. It's easier to do this than to backfill the dict we pass in.
Augie Fackler <augie@google.com> [Mon, 23 Nov 2015 10:13:05 -0500] rev 27086
histedit: constant-ify the constraints list
Used a class as a namespace, and then wired up a classmethod to return
all known constraints. I'm mostly happy with this, even though it's
kind of weird for hg.
Mateusz Kwapich <mitrandir@fb.com> [Tue, 17 Nov 2015 15:04:31 -0800] rev 27085
histedit: add an experimental base action
This is a first (very simple) version of the histedit base action.
It works well in common usecases like rebasing the whole stack and
spliting the stack.
I don't see any obvious edge cases - but probably there is more than one.
That's why I want to keep it behind experimental.histeditng config knob
for now. I think on knob for all new histedit behaviors is better because
we will test all of them together and testers will need to turn it on only
once to get all new nice things.
Mateusz Kwapich <mitrandir@fb.com> [Tue, 17 Nov 2015 17:53:52 -0800] rev 27084
histedit: add abortdirty function
Small helper function for aborting histedit when left with dirty working
directory.
Mateusz Kwapich <mitrandir@fb.com> [Thu, 12 Nov 2015 16:40:33 -0800] rev 27083
histedit: add forceother constraint
For the future 'base' action in histedit we need a verification
constraint which will not allow using this action with changes
that are currently edited.
Mateusz Kwapich <mitrandir@fb.com> [Tue, 17 Nov 2015 16:37:26 -0800] rev 27082
histedit: make verification configurable
Before we can add a 'base' action to histedit need to change verification
so that action can specify which steps of verification should run for it.
Also it's everything we need for the exec and stop actions implementation.
I thought about baking verification into each histedit action (so each
of them is responsible for verifying its constraints) but it felt wrong
because:
- every action would need to know its context (eg. the list of all other
actions)
- a lot of duplicated work will be added - each action will iterate through
all others
- the steps of the verification would need to be extracted and named anyway
in order to be reused
The verifyrules function grows too big now. I plan to refator it in one of
the next series.
Anton Shestakov <av6@dwimlabs.net> [Fri, 13 Nov 2015 18:31:58 +0800] rev 27081
paper: show current revision on file log page
Most of the pages in paper (and coal) style show the current revision and its
branch, tags and bookmarks. Let's also show all this on file log page.
Siddharth Agarwal <sid0@fb.com> [Fri, 20 Nov 2015 11:26:31 -0800] rev 27080
merge.applyupdates: extend action queues with ones returned from mergestate
These queues will always be empty at the moment -- we're going to fill them up
in upcoming patches.
Siddharth Agarwal <sid0@fb.com> [Fri, 20 Nov 2015 16:43:25 -0800] rev 27079
mergestate: add a method to compute actions to perform on dirstate
We're going to use this to extend the action lists in merge.applyupdates.
The somewhat funky return value is to make passing this dict directly into
recordactions easier. We're going to exploit that in an upcoming patch.
Siddharth Agarwal <sid0@fb.com> [Fri, 20 Nov 2015 16:37:39 -0800] rev 27078
merge.applyupdates: use counters from mergestate
This eliminates a whole bunch of duplicate code and allows us to update the
removed count for change/delete conflicts where the delete action was chosen.