Largefiles update would try to copy f to f.orig if there was a .hglf/f.orig .
That is in many many ways very very wrong, but it also caused an abort if f
didn't exist.
Now it only tries to copy f if it exists.
Problem: 'hg status' with largefiles enabled would walk through all the files
that .hgignore said should be ignored. That made it slow if a lot of files were
.hgignored or the cache was cold.
It seems like there was a reason to this, but other improvements has rendered
this unnecessary.
Solution: .hgignore is now only ignored when that is requested (--ignore).
This is a minimal 'stable' change. There is room for other improvement.
Largefiles revert do for some reason have two lfdirstates and lfdirstatestatus
invocations in one function. The result from the first lfdirstate check was
however not written back to the lfdirstate, and some files was thus checked
twice.
Problem: 'hg status' kept checking largefiles with an unknown state until some
other command wrote the updated dirstate.
Solution: Add missing lfdirstate.write().
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.
Simplify core logic by no longer attempting to work around missing
class attributes. Instead always generate the attributes and ignore
the cache if the attributes are missing
If we pass a directory to commit whose only commitable files
are largefiles, the core commit code aborts before finding
the largefiles.
So we do the following:
For directories that only have largefiles as matches,
we explicitly add the largefiles to the matchlist and remove
the directory.
In other cases, we leave the match list unmodified.
Rebase also have a plain `--rev` option used to select the rebase set (as
`--base` or `--source` would). But the content of the --rev option was intended
for the remote repo and is irrelevant for the local rebase operation. We expect
`hg pull --rebase` to stick with the default behavior here:
hg rebase --base . --dest tip(branch(.))
The `rev` option is dropped from the option passed to rebase.
Strip have dedicated work around to solve the same problem, strip is even a
fraction faster without that thanks to simpler update process of the branchcache.
Obsolescence markers can represent this situation just fine. Rewritten
revisions are marked as precursors of the ones creates by
histedit. Unaffected descendants become "unstable".
If obsolescence is not enabled we keep the current behavior of
aborting. This new behavior only applies when obsolete is
enabled and is subject to future discussion and changes.
Obsolescence markers can represent this situation just fine. Rebased
revisions are marked as precursors of the ones create by
rebase. Unrebased descendants becomes "unstable".
If obsolescence is not enabled we keep the current behavior of
aborting. This new behavior only applies when obsolete is
enabled and is subject to future discussion and changes.
Especially the "no default or default-push path set in hgrc" was often very
misleading and didn't give any hint where it actually was looking.
A long error messages is better than several multi-line messages.
The current _branchtags method is a remnant of an older, much larger function.
Its only remaining role is to help MQ to alter the version of branchcache we
store on disk. As MQ mutates the repository it ensures persistent cache does not
contain anything it is likely to alter.
This changeset makes explicit the stable vs volatile part of repository and
reduces the MQ specific code to the computation of this limit. The main
_branchtags code now handles this possible limit in all cases.
This will help to extract the branchmap logic from the repository.
The new code of _branchtags is a bit duplicated, but as I expect major
refactoring of this section I'm not keen to setup factorisation function here.
We also turn the unix domain socket into a class, so that we have a
sensible place to hang its logically related attributes and behaviour.
We'll shortly want to reuse this in other code.
Previously, the inotify server failed to start if .hg/inotify.sock was
a symlink that pointed to a non-existent path. This behaviour does not
seem to make any sense.
Now, if we encounter a broken symlink, we unlink it and continue.
For a repository with over 400,000 commits, rebasing one revision near tip,
this avoids one walk up the DAG, speeding the operation up by around 0.8
seconds.
The check pattern only checked for whitespace between keyword and operator.
Now it also warns:
> x = f(),7
missing whitespace after ,
> x = f()+7
missing whitespace in expression
Before this patch, largefiles extension uses "largefiles: No remote
repo" message not only for "outgoing" as status report, but also for
"summary" as summarized information.
This sharing prevents message translators from inserting white spaces
between "largefiles:" and "No remote repo" in translated message to
align column position of summarized information.
This patch changes output of largefiles for summary to distinguish
from one for outgoing.
This patch puts "no remote repo" into parentheses, because this is not
summarized information.
Before this patch, one of column positioning messages of MQ summary
output is not translatable, and patches are always listed up at fixed
column position like below, when patch queue is not empty:
mq: 1 applied, 1 unapplied
But column positioning messages for other summarized information are
translatable, so other information may be displayed at different
column position on non-English locale environments.
This patch makes column positioning message of MQ summary output
translatable.
