histedit: move `continue` logic into a dedicated function
When histedit "continue", there is several complicated logic to apply in order to
detect intermediate changeset and concluded pending operation.
This changeset extract this logic in a dedicated function to lighten the main
one. No alteration to the logic is done.
histedit: rename `tip` to `topmost`
I expected `tip` to be repo's tip when it was the rewritten set tip. I rename
the variable to the less ambiguous `topmost`.
histedit: factorise node stripping logic
Create a function dedicated to stripping a group of node. All existing
duplicated code is replaced by call to this function.
This new function take care of stripping known and relevant node only.
histedit: extract bookmark logic in a dedicated function
This lighten the main function and will help to see future changes to this
bookmark logic.
histedit: remove all usages of hex[:12]
- `node.hex(n)[:12]` is the same as `node.short(n)`
- `ctx.hex()[:12]` is the same as `str(ctx)`
largefiles: enable islfilesrepo() prior to a commit (
issue3541)
Previously, even if a file was added with --large, 'hg addremove' or 'hg ci -A'
would add all files (including the previously added large files) as normal
files. Only after a commit where a file was added with --large would subsequent
adds or 'ci -A' take into account the minsize or the pattern configuration.
This change more closely follows the help for largefiles, which mentions that
'add --large' is required to enable the configuration, but doesn't mention the
previously required commit.
Also, if 'hg add --large' was performed and then 'hg forget <file>' (both before
a largefile enabling commit), the forget command would error out saying
'.hglf/<file> not tracked'. This is also fixed.
This reports that a repo is largefiles enabled as soon as a file is added with
--large, which enables 'add', 'addremove' and 'ci -A' to honor the config
settings before the first commit. Note that prior to the next commit, if all
largefiles are forgotten, the repository goes back to reporting the repo as not
largefiles enabled.
It makes no sense to handle this by adding a --large option to 'addremove',
because then it would also be needed for 'commit', but only when '-A' is
specified. While this gets around the awkwardness of having to add a largefile,
then commit it, and then addremove the other files when importing an existing
codebase (and preserving that extra commit in permanent history), it does still
require finding and manually adding one of the files as --large. Therefore it
is probably desirable to have a --large option for init as well.
largefiles: handle commit -A properly, after a --large commit (
issue3542)
Previous to this, 'commit -A' would add as normal files, files that were already
committed as largefiles, resulting in files being listed twice by 'status -A'.
It also missed when (only) a largefile was deleted, even though status reported
it as '!'. This also has the side effect of properly reporting the state of the
affected largefiles in the post commit hook after a remove that also affected a
normal file (the largefiles used to be 'R', now are properly absent).
Since scmutil.addremove() is called both by the ui command (after some trivial
argument validation) and during the commit process when -A is specified, it
seems like a more appropriate method to wrap than the addremove command.
Currently, a repo is only enabled to use largefiles after an add that explicitly
identifies some file as large, and a subsequent commit. Therefore, this patch
only changes behavior after such a largefile enabling commit.
Note that in the test, if the final commit had a '-v', 'removing large8' would
be printed twice. Both of these originate in removelargefiles(). The first
print is in verbose mode after traversing remove + forget, the second is because
the '_isaddremove' attr is set and 'after' is not.
i18n-ru: synchronized with
6e2ab601be3f