Store in effect flag when the date changed between the predecessor and
its successors.
It can happens with "hg commit --amend -d", "hg amend -d" or "histedit".
Differential Revision: https://phab.mercurial-scm.org/D537
Store in effect flag when the user changed between the predecessor and its
successors.
It can happens with "hg commit --amend -u" or "histedit".
Differential Revision: https://phab.mercurial-scm.org/D536
Store in effect flag when the description changed between the predecessor and
its successors.
It can happens with "hg commit --amend -e", "hg amend -e" or "histedit".
Differential Revision: https://phab.mercurial-scm.org/D535
The idea behind effect flag is to store additional information in obs-markers
about what changed between a changeset and its successor(s). It's a low-level
information that comes without guarantees.
This information can be computed a posteriori, but only if we have all
changesets locally. This is not the case with distributed workflows where you
work with several people or on several computers (eg: laptop + build server).
Storing the effect-flag as a bitfield has several advantages:
- It's compact, we are using one byte per obs-marker at most for the effect-
flag.
- It's compoundable, the obsfate log approach needs to display evolve history
that could spans several obs-markers. Computing the effect-flag between a
changeset and its grand-grand-grand-successor is simple thanks to the
bitfield.
The effect-flag design has also some limitations:
- Evolving a changeset and reverting these changes just after would lead to
two obs-markers with the same effect-flag without information that the first
and third changesets are the same.
The effect-flag current design is a trade-off between compactness and
usefulness.
Storing this information helps commands to display a more complete and
understandable evolve history. For example, obslog (an Evolve command) use it
to improve its output:
x 62206adfd571 (34302) obscache: skip updating outdated obscache...
| rewritten(parent) by Matthieu Laneuville <matthieu.laneuville@octobus...
| rewritten(content) by Boris Feld <boris.feld@octobus.net>
The effect flag is stored in obs-markers metadata while we iterate on the
information we want to store. We plan to extend the existing obsmarkers
bit-field when the effect flag design will be stabilized.
It's different from the CommitCustody concept, effect-flag are not signed and
can be forged. It's also different from the operation metadata as the command
name (for example: amend) could alter a changeset in different ways (changing
the content with hg amend, changing the description with hg amend -e, changing
the user with hg amend -U). Also it's compatible with every custom command
that writes obs-markers without needing to be updated.
The effect-flag is placed behind an experimental flag set to off by default.
Hook the saving of effect flag in create markers, but store only an empty one
for the moment, I will refine the values in effect flag in following patches.
For more information, see:
https://www.mercurial-scm.org/wiki/ChangesetEvolutionDevel#Record_types_of_operation
Differential Revision: https://phab.mercurial-scm.org/D533
successorssets don't returns good results for pruned commit, add a workaround
for simple cases.
A proper fix would require a large rework of successorssets algorithm, I will
send a separate series for this refactoring.
Extract, deduplicate users informations from obs markers in order to display
them.
Print all users for the moment, we might want to display users only in verbose
mode later.
Add a template function obsfateverb which use the markers information to
compute a better obsfate verb.
The current logic behind the obsfate verb is simple for the moment:
- If the successorsets is empty, the changeset has been pruned, for example:
Obsfate: pruned
- If the successorsets length is 1, the changeset has been rewritten without
divergence, for example:
Obsfate: rewritten as 2:337fec4d2edc, 3:f257fde29c7a
- If the successorsets length is more than 1, the changeset has diverged, for
example:
Obsfate: split as 2:337fec4d2edc, 3:f257fde29c7a
As the divergence might occurs on a subset of successors, we might see some
successors twice:
Obsfate: split as 9:0b997eb7ceee, 5:dd800401bd8c, 10:eceed8f98ffc; split
as 8:b18bc8331526, 5:dd800401bd8c, 10:eceed8f98ffc
The goal of this series is to have templates capable of displaying the
evolution of a changeset in a clean and human-readable way.
Add the succsandmarkers template return successors and markers so it can be
used separately like this:
> {succsandmarkers % "{get(succsandmarkers, "markers")|json};"}
The following patches will add template functions that takes successors and
markers as inputs and compute various obsfate fields from them.
We now also store markers in _succs. It will be useful for the obsfate template that
will use them to display more meaningful information like the list of users
that have evolved a changeset into its successors.
Mimic the standard API for copying in the _succs class, it makes the code
slightly cleaner and will be needed later for copying markers at the same time
than copying the list content.
It will be useful later when we will be adding markers to _succs in order to
represent a successorset with the list of markers from the root to each
successors sets. This information will be needed for the obsfate template I will
introduce.
Makes it a subclass of list so all callers will continue to work.
I'm not sure if this is a realistic problem, but doing this avoids
some pretty awful test failures on Python 3, and it looks like it
should be harmless.
Differential Revision: https://phab.mercurial-scm.org/D274
Add a closest argument to successorssets changing the definition of latest
successors.
With "closest=false" (current behavior), latest successors are "leafs" on the
obsmarker graph. They don't have any successor and are known locally.
With "closest=true", latest successors are the closest locally-known
changesets that are visible in the repository or repoview. Closest successors
can be then obsolete, orphan.
This will be used in a later patch to show the closest successor of
changesets with the successorssets template.
Clarify successorssets documentation before we start updating the main function.
This patch serie will introduce the successorssets template, the opposite of
predecessor templates.
Successors will use successorssets function and requires some improvement so
before doing that, we clean up successorssets a bit.
This is a first basic visible usage of the changes tracking in the transaction.
We adds a new function computing the pre-existing changesets obsoleted by a
transaction and a transaction call back displaying this information.
Example output:
added 1 changesets with 1 changes to 1 files (+1 heads)
3 new obsolescence markers
obsoleted 1 changesets
The goal is to evolve the transaction summary into something bigger, gathering
existing output there and adding new useful one. This patch is a good first step
on this road. The new output is basic but give a user to the content of
tr.changes['obsmarkers'] and give an idea of the new options we haves. I expect
to revisit the message soon.
The caller recording the transaction summary should also be moved into a more
generic location but further refactoring is needed before it can happen.
Add a 'predecessors' template that returns the list of all closest known
predecessors for a changectx. The elements of the list are row changectx node id
formatted by default as short nodes.
The "closest predecessors" are the first locally known revisions encountered
while, walking predecessors markers. For example:
1) If a (A, (B)) markers exists and both A and B are locally known A is a
closest predecessors of B.
2) If a (A, (B)) and (B, (C)) markers exists and only A and C are known
locally, A will be the closest precursors of C.
This logic respect repository filtering. So hidden revision will be skipped by
this logic unless --hidden is specified. Since we only display the visible
predecessors, this template will not display anything in most case. It makes a
good candidate for inclusion in the default log output.
I added a new test-file for testing the precursors in various scenarios. This
test file will also be used for the successors template.
A new "obsutil" module has been added to start gathering utility function
outside of the large obsolete.py module.
