The dispatch code now enables filtering of "hidden" changesets globally. The
filter is installed before command and extension invocation. The `--hidden`
switch is now global and disables this filtering for any command.
Code in log dedicated to changeset exclusion is removed as this global filtering
has the same effect.
When log is not given the --hidden option, hidden revision are not shown. We
move the implementation from manual checking at display time to changelog
filtering.
This is the first official usage of the hidden filtering.
The active bookmark were moved to the temporary commit. When the transaction
were rollbacked, the bookmark were lost.
We now temporarly disable the bookmark to prevent this effect.
The temporary commit created by amend update the dirstate. If the final commit
fails, we need to invalidate the change made to the dirstate, otherwise the
release of the wlock will write the dirstate created after the rollbacked
temporary commit.
This dirstate writing logic should probably be handled in the same object than
the transaction one. However such change are too big for stable.
cmdutil.getgraphlogrevs does a ton of work trying to build a graphlog lazily,
and then cmdutil.graphlog comes along and destroys all of that.
graphmod.dagwalker requires that it be given the full list of revs upfront so
that it can perform filtering and tests against known revs.
For a repository with over 400,000 changesets, this speeds up graphlog by
around 0.02 seconds (~20% with a small limit).
Color extension achieves colorization by overriding the class of
"ui" object just before command execution.
Before this patch, "diff()" of abstractsubrepo and classes
derived from it has no "ui" argument, so "diff()" of hgsubrepo
uses "self._repo.ui" to invoke "cmdutil.diffordiffstat()".
For separation of configuration between repositories, revision
1498948ee815 changed the initialization source of "self._repo.ui"
from "ui"(overridden) to "baseui"(plain) of parent repository.
And this caused break of colorization.
This patch adds "ui" argument to "diff()" of abstractsubrepo and
classes derived from it to pass "ui" object of caller side.
Bookmarks persistence still showed a fair amount of its legacy as a
monkeypatching extension. This encapsulates all bookmarks
serialization and parsing in a single class, and offers a single
location where other bookmarks storage engines can be substituted
in. As a result, many files no longer import the bookmarks module,
which strikes me as an encapsulation win.
This doesn't do anything to the current bookmark state yet, but I'm
hoping put that in the bmstore class as well.
Before this changeset the temporary changeset created by amend was made a
precursors on the amend result. This add unnecessary complexity to the
obsolescence graph. This temporary commit will probably disappear in the future.
It is an unwanted byproduct of amend that nobody cares about.
Obsolescence cycle are bad and should be avoided as much as possible. The
current amend implemented touch changeset meta data as few as possible. This
make is easy for amend to result in the same node than a precursors. We add some
deterministic noise in extra to avoid this. In practice, the hex of the amended
changeset is stored in 'amend_source' extra key.
This allows the user to set different colors for each phase, e.g.
[color]
changeset.public = blue
changeset.draft = green
changeset.secret = red
In addition, this doesn't affect current configuration for custom log.changeset
colors, but rather adds the option for users that want to visually see which
changesets are amendable.
'hg log' on untracked files tends to be fairly slow. The root cause is that we end up using the 'slowpath' when we can't find a revlog for the files listed. This could happen if the file in question is an untracked file, or it is a directory.
This diff tries to speed up 'hg log' (by avoiding the slowpath) for files if we can determine if that file is not (and was never) a directory. We use the previously added store.__contains__ methods to test if the directory exists (or existed) in the store.
To avoid changing any existing semantics, this 'optimization' kicks in only when none of the files listed as arguments to the hg log command exist in the store.
Before this changeset, the extra commit created during amend had
the same description as the final commit. This was a bit confusing
when trying to understand what that extra commit was about.
This changeset changes the description of such commit to:
temporary amend commit for <ammend-commit-hash>
The old behaviour was not a big deal, but would become more confusing
once we use obsolescence marker instead of stripping the precursors.
This also helps if the user restores a strip backup.
This allows proper recovery of an interrupted amend process.
No changes are made to the logic besides:
- indent operations into a single try-except clause,
- some comment and code wrapping to 80 chars,
- strip logic should not be contained in the transaction and is extracted from
the main code.
New commit from the amend process were created without any phase contraint. If
the amended changeset had a different phase from it's parent, the phases data
were lost.
The changeset ensure the new commit are created in the same phase than the
original changeset.
The export command didn't output the diffs in color, even when color support
was enabled. This patch fixes that by making the export command use the default
ui.write method, instead of directly manipulating the ui.fout file object.
Also added a test case to verify color output to test-export.t.
This set is always accessed through the repo for now. Having this set
carried by the changelog make it complicated to:
- initialize it, computing hidden set may involve revset call
- lazy compute it, (1) only the changelog can detect someone access it,
(2) only the repo have enought knowledge to compute it.
In later version I expect he changelog to apply filtering itself and the set to
be carried by changelog again.
Messing with the dirstate before the intermediate commit seems error prone.
Instead, commit and recompute the copies with copies.pathcopies(), then use
that with commitctx().
Since copies.pathcopies() does not support file replacement very well, the
whole .renamed() condition in samefile() is removed and the "file replacement
caused by differing copy source" effect is discarded.
Test shamelessly stolen from Idan Kamara <idankk86@gmail.com>
The fix introduced in 3509b9cf8f86 was only partially successful. It is correct
to turn dirstate 'm' merge records into normal/dirty ones but copy records are
lost in the process. To adjust them as well, we need to look in the first
parent manifest to know which files were added and preserve only related
records. But the dirstate does not have access to changesets, the logic has to
moved at another level, in localrepo.
