In paper, coal, gitweb and monoblue a new "tag" (or multiple, if there are many
instabilities) is added to the same line that has phase, branch, etc of a
changeset; in gitweb and monoblue this element has a light red background, in
paper and coal the element is black and underlined. In spartan theme
instabilities are shown on a separate line.
While test-obsolete.t uses first(phasedivergent()) revset to pick a changeset
to test, that particular changeset is also an orphan, so two different
instability tags are displayed.
As with phases, spartan theme shows a simple "obsolete: yes" on its own line
(this allows replacing "yes" with something more useful in future, like output
of obsfate* template functions). Everywhere else a new "tag" is added to the
same line that has phase, branch, etc of a changeset; in gitweb and monoblue
the element has gray background, in paper and coal the element is gray with a
dashed underline.
Yuja's comment on the original obsfate about how we would translate obsfate
and the recent discussions about exposing users to new concepts and names lead
have led me to think that 'obsfate' should be treated as internal jargon. End-
users should not be aware of obsfate, so we replace 'obsfate' by 'obsolete' in
changeset_printer.
It will be easier to understand for end-users, easier to translate and closer
to the original Evolve obsfate output.
I'm aware it's extremely late in the cycle but I think it's an UX improvement
for the end-users.
Differential Revision: https://phab.mercurial-scm.org/D1189
We want to get rid of stabilization.* configuration, back out to the old
configuration 'evolution.track-operation'.
Differential Revision: https://phab.mercurial-scm.org/D1153
Extract 'experimental.evolution' = exchange as
'experimental.evolution.exchange'.
We keep the new option in the 'experimental.evolution' namespace in order to
stay coherent with other options ('experimental.evolution.bundle-obsmarker'
and 'experimental.evolution.track-operation') ease the renaming as possibly
'evolution.exchange'.
Differential Revision: https://phab.mercurial-scm.org/D1151
Extract 'experimental.evolution' = createmarkers as
'experimental.evolution.createmarkers'.
We keep the new option in the 'experimental.evolution' namespace in order to
stay coherent with other options ('experimental.evolution.bundle-obsmarker'
and 'experimental.evolution.track-operation') ease the renaming as possibly
'evolution.createmarkers'.
Differential Revision: https://phab.mercurial-scm.org/D1149
Use the verbosity aware template keyword introduced earlier. It has the nice
property of being verbosity dependent but in order to customize the obsfate
part, users will need to replace the lobsfate definition from default mapfile
with the one using template functions (by copying the one from test-obsmarker-
template.t for example).
As it's a more advanced use-case, I'm more inclined to have the same code for
the {obsfate} keyword, in the changeset printer and in the default mapfile for
consistency.
But, the definition in default mapfile could be replaced with one based on
template filter to obsfate output customization if it is a big need for users.
Having an obsfate by default in log will be useful for users to understand why
they have obsolete and unstable changesets. Obsfate will only be shown for
obsolete changesets, which only happens if people opt-in to experimental feature.
But when obsolete changeset are visible, it is very useful to understand where
they are. Having it in log could be sufficient for most people, so they don't
have to learn a new command (like obslog which is itself useful in case of
divergences).
For example, when pulling and working directory parent become obsolete:
$ hg pull
...
working directory parent is obsolete! (f936c1697205)
This message comes from the Evolve extension.
Obsfate would comes handy:
$ hg log -G
o changeset: 2:6f91013c5136
| tag: tip
| parent: 0:4ef7b558f3ec
| user: Boris Feld <boris.feld@octobus.net>
| date: Mon Oct 09 16:00:27 2017 +0200
| summary: A
|
| @ changeset: 1:f936c1697205
|/ user: Boris Feld <boris.feld@octobus.net>
| date: Mon Oct 09 16:00:27 2017 +0200
| obsfate: rewritten using amend as 2:6f91013c5136
| summary: -A
|
o changeset: 0:feb4dd822b8c
user: Boris Feld <boris.feld@octobus.net>
date: Tue Oct 09 16:00:00 2017 +0200
summary: ROOT
And once we update, we don't have an obsolete changeset in the log anymore so
we don't show obsfate anymore, most users won't see obsfate often if they
don't have obsolete changeset often:
@ changeset: 2:6f91013c5136
| tag: tip
| parent: 0:4ef7b558f3ec
| user: Boris Feld <boris.feld@octobus.net>
| date: Mon Oct 09 16:00:27 2017 +0200
| summary: A
|
o changeset: 0:feb4dd822b8c
user: Boris Feld <boris.feld@octobus.net>
date: Tue Oct 09 16:00:00 2017 +0200
summary: ROOT
Obsolescence is sometimes used only locally so the obs-marker users is always
the same. Showing the user in this case does not bring much values.
In the case where multiple users rewrite the commit, display the full list of
users. Also show all users in verbose mode.
Introduce an obsfate printer that uses all helpers functions defined in
obsutil to get all the obsfate-related data and format a string according to
the current format in test-obsmarker-template.t.
Then, introduce an obsfate templatekw that uses the obsfateprinter to return a
list of strings.
The goal is not to replace existing obsfate template functions but to propose
a default, good-enough and easily usable obsfate definition for end-users that
don't want to customize it. Such output would ultimately get included in the
default log output.
Here are some output examples for a commit amended:
rewritten using amend as 5:a9b1f8652753 by test (at 1970-01-01 00:00 +0000)
Next patches will make the output dependent on the verbosity.
Exemple of use-cases:
For having the obsfate on a single-line between brackets:
{if(obsfate, " [{join(obsfate, "; ")}]")}
For having the obsfate in several lines:
{if(obsfate, "{obsfate % " Obsfate: {fate}\n"}")}
Upon pull or unbundle, we display a message with the range of new revisions
fetched. This revision range could readily be used after a pull to look out
what's new with 'hg log'. The algorithm takes care of filtering "obsolete"
revisions that might be present in transaction's "changes" but should not be
displayed to the end user.
Before, _hybrid.gen must be a generator which could be consumed only once.
It was okay in templatekw.py since template keywords are functions which
create temporary hybrid objects, but the formatter doesn't work in that way.
To work around the issue, this patch makes _hybrid.gen optionally be a
function returning a generator.
Thanks to Pulkit for finding this issue.
We added support for including the operation responsible for creating
the obsmarker in 44ba6434eaf4 (obsolete: add operation metadata to
rebase/amend/histedit obsmarkers, 2017-05-09). However, soon
thereafter, in 819cf35e629a (obsmarker: add an experimental flag
controlling "operation" recording, 2017-05-20), it was hidden behind a
config that was off by default. It seems unlikely that people will
manually turn it on, and obsmarkers/evolution as a whole is still
experimental anyway, so let's turn on the tracking by default.
Differential Revision: https://phab.mercurial-scm.org/D722
Since the redundant commit during the amend has been been removed, there is no
need for commit callback function in amend now. Therefore, this commit removes
the unused parameter "commmitfunc" which was being used for this purpose.
Test Plan:
Ensured that all the tests pass
Differential Revision: https://phab.mercurial-scm.org/D635
There was an extra commit made during the amend operation to track the
changes to the working copy. However, this logic was written a long time back
and newer API's make this extra commit redundant. Therefore, I am removing the
extra commit. After this change, I noticed that
- Execution time of the cmdutil.amend improved by over 40%.
- Execution time of "hg commit --amend" improved by over 20%.
Test Plan:
I ensured that the all the hg tests passed after the change. I had
to fix a few tests which were aware of the extra commit made during the amend.
Differential Revision: https://phab.mercurial-scm.org/D636
Update all calls to formatter.write first arguments to remove references to
precnode and use prednode consistently everywhere.
Differential Revision: https://phab.mercurial-scm.org/D414
evolution* config has been rewritten in stabilization* in the previous patch,
update tests file to use the new names.
Differential Revision: https://phab.mercurial-scm.org/D249
Rename bumped to phase-divergent in all external user-facing output. Only
update user-facing output for the moment, variables names, templates keyword
and potentially configuration would be done in later series.
The renaming is done according to
https://www.mercurial-scm.org/wiki/CEDVocabulary.
Differential Revision: https://phab.mercurial-scm.org/D216
Rename unstable to orphan in all external user-facing output. Only update
user-facing output for the moment, variables names, templates keyword and
potentially configuration would be done in later series.
The renaming is done according to
https://www.mercurial-scm.org/wiki/CEDVocabulary.
Differential Revision: https://phab.mercurial-scm.org/D214
Now that we have migrated all in-core caller of 'recordchange' to
'applychanges', deprecate 'recordchange' so external callers will move to the
new unified method.
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.
Before this patch, unbundling a stripped changeset would make it a
draft (unless the parent was secret). This meant that one would lose
phase information when stripping and unbundling secret changesets. The
same thing was true for public changesets. While stripping public
changesets is generally rare, it's done frequently by e.g. the
narrowhg extension.
We also include the phases in the temporary bundle, just in case
stripping were to fail after that point, so the user can still restore
the repo including phase information. Before this patch, the phases
were left untouched during the bundling and unbundling of the
temporary bundle. Only at the end of the transaction would
phasecache.filterunknown() be called to remove phase roots that were
no longer valid. We now need to call that also after the first
stripping, i.e. before applying the temporary bundle. Otherwise
unbundling the temporary bundle will cause a read of the phase cache
which has stripped changesets in the cache and that fails.
Like with obsmarkers, we unconditionally include the phases in the
bundle when stripping (when using bundle2, such as when generaldelta
is enabled). The reason for doing that for strip but not for bundle is
that strip bundles are not meant to be shared outside the repo, so we
don't care as much about compatibility.
This is it, `hg strip --rev X` will now also remove obsolescence markers
exclusive to X. Since a previous changeset, the obsmarkers has been backed up
in the strip backup bundle, so it is possible to restore them.
Note: stripping obsmarkers means the precursors of the stripped changeset might no
longer be obsolete after the strip.
Stripping changeset without obsmarkers can be useful when building test case. So
It is possible to disable the stripping of obsmarkers using the
'devel.strip-obsmarkers' config option.
Test change have been carefully validated.
This set will be used to select the obsmarkers to be stripped alongside the
stripped changesets. See the function docstring for details.
More advanced testing is introduced in the next changesets to keep this one
simpler. That extra testing provides more example.
We are about to give 'strip' the ability to remove obsmarkers. Before we start
removing data we must make sure it is preserved somewhere. So the backup bundle
created by 'strip' now contains obsmarkers.
The improvement in time complexitty and the speed-up in computation is large
enough that the has little use now. Its update time can even gets in the way. So
we drop it.
This will allow us to unify the static/dynamic blockers logic in the next
changeset.
Also use the default-date when creating obsmarkers. Currently they are created
with the current date and without any option to force their value.
To test the feature, we remove some of the many 'glob' used to match obsmarker
date in the tests.
Receiving markers affecting changeset we'll receives later is legitimate and
not so uncommon case. Working on cache highlighted that this was only testing
in the evolve extension. We add a test for this case in core.
It seems better to introduce the experiment behind a flag for now as there are
multiple concerns around the feature:
* Storing operation increase the size of obsolescence markers significantly
(+10-20%).
* It performs poorly when exchanging markers (cannot combine command names,
command name might be unknown remotely, etc)
cmdutil.command wasn't a member of the registrar framework only for a
historical reason. Let's make that happen. This patch keeps cmdutil.command
as an alias for extension compatibility.
By recording what operation created the obsmarker, we can show very intuitive
messages to the user in various UIs. For instance, log output could have
messages like "Amended as XXX" to show why a commit is old and has an 'x' on it.
@ ac28e3 durham
/ First commit
|
| o d4afe7 durham
| | Second commit
| |
| x 8e9a5d (Amended as ac28e3) durham
|/ First commit
|
