mergestate: rename a helpless variable name to bit helpful one
The old variable name `r` makes it ~impossible to understand what does it mean.
One can only understand that after going to callers and hoping that its
documented there.
I also documented return value of the function involved while I was there.
Differential Revision: https://phab.mercurial-scm.org/D8738
mergestate: remove unnecessary recordactions() from mergestate class
This function is updating dirstate which sounds like not something which a
method on mergestate class should do. Also this just calls another function.
Lets directly call that function and remove this reducing mergestate
responsibility a bit.
There was single caller which is updated.
Differential Revision: https://phab.mercurial-scm.org/D8737
mergestate: document mergestate records in an organized way
This makes clear which mergestate record is used for what and group them based
on how they are used right now.
Differential Revision: https://phab.mercurial-scm.org/D8719
mergestate: remove unused unsupported related mergestate records
I tried to find users of this but was unable to find. Seems like RECORD_OVERRIDE
is doing for what they were used before.
Differential Revision: https://phab.mercurial-scm.org/D8718
mergestate: add comments about couple of record types and minor reorder
I am trying to divide the records into certain groups and then have dedicated
objects for them. Taking baby steps in that direction.
Differential Revision: https://phab.mercurial-scm.org/D8717
mergestate: remove unrequired RECORD_RESOLVED_OTHER record
This was introduced in last cycle however while working on refactoring
mergestate, I realized it's unncessary.
This will break users who did a merge using previous version, did this kind of
storage and before commiting updated the mercurial version.
Differential Revision: https://phab.mercurial-scm.org/D8716
mergestate: rename addpath() -> addpathonflict() to prevent confusion
addpath() seems to imply that we are adding a new path/entry to the mergestate.
Differential Revision: https://phab.mercurial-scm.org/D8715
windows: don’t set `softspace` attribute in `winstdout`
Python 2 file objects have the `softspace` attribute
(https://docs.python.org/2/library/stdtypes.html#file.softspace), which is used
by the print statement to track its internal state. The documentation demands
from file-like objects only that the attribute is writable and initialized to
0. Method `file.write()` sets it to 0, but this is not documented.
Historically, sys.stdout was replaced by an instance of the `winstdout` class,
so it needed to behave exactly the same (the softspace fix was introduced in
705278e70457). Nowadays we don’t replace sys.stdout and don’t use the print
statement on `winstdout` instances, so we can safely drop it.
windows: handle file-like objects without isatty() method
Copying the function is not nice, but moving around stuff to avoid the
circular import didn’t seem to be worth the effort.
exchange: check actually missing revs for obsolete / unstable revs (
issue6372)
The previous code was using `outgoing.ancestorsof`, which was originally called
`outgoing.missingheads` although not containing the missing heads. This
confusion was probably the reason why the buggy code was written.
The actually outgoing changesets are stored in `outgoing.missing`. By checking
all outgoing changesets, we avoid the problem and can show the list of all
obsolete or unstable changesets, which is more helpful for the user.