We would formerly exec git cat-file once for every commit, plus once for
every tree and file we wnated to read. This switches to using git
cat-file's batch mode, which is much, much, much faster.
Using this new code, converting the git git repo to hg ran in 106
minutes on my machine. Using the stock mercurial, it required 1239
minutes. I believe this to be typical of the speedups we will see
form this patch.
This replaces the grand unified action list that had multiple action types as
tuples in one big list. That list was iterated multiple times just to find
actions of a specific type. This data model also made some code more
convoluted than necessary.
Instead we now store actions as a tuple of lists. Using multiple lists gives a
bit of cut'n'pasted code but also enables other optimizations.
This patch uses 'if True:' to preserve indentations and help reviewing. It also
limits the number of conflicts with other pending patches. It can trivially be
cleaned up later.
Changes rebase conflict markers to say 'source' and 'dest' instead of
'local' and 'other'. This ends up looking like:
one
<<<<<<< dest: a3e5c7fd master - bob: "A commit to master"
master
=======
mine
>>>>>>> source: c7fda3e5 - durham: "A commit to my feature branch"
three
Adds a labels function parameter to all the functions between merge.update and
filemerge.filemerge. This will allow commands like rebase to specify custom
marker labels.
cat of a standin would silently fail.
The use of standins is mostly an implementation detail, but it is already a bit
leaking. Being able to see the content of standins might be convenient for
debugging.
A .orig of a standin after the update do that a .orig of the actual largefile
is created. The .orig standin was however never removed again and the largefile
.orig was thus overwritten again and again.
The fix: remove the standin .orig when it is used.
Closemap solves a very specific use case. It would be better to have a more
generic solution than to have to maintain this forever.
Closemap has not been released yet and removing it now will not break any
backward compatibility contract.
There is no test coverage for closemap but it seems like the same can be
achieved with a simple and much more powerful custom extension:
import hgext.convert.hg
class source(hgext.convert.hg.mercurial_source):
def getcommit(self, rev):
c = super(source, self).getcommit(rev)
if rev in ['''
d643f67092ff123f6a192d52f12e7d123dae229f
3a6a38229d418ba09cb7784c01453a93b4d363f8
facceca31c18f7ef800977055dbcbd7fcb5c5cb2
''']:
c.extra = c.extra.copy()
c.extra['close'] = '1'
return c
hgext.convert.hg.mercurial_source = source
Tagmap solves a very specific use case. It would be better to have a more
generic solution than to have to maintain this forever.
Tagmap has not been released yet and removing it now will not break any
backward compatibility contract.
There is no test coverage for tagmap but it seems like the same can be achieved
with a (relatively) simple and much more powerful custom extension:
import hgext.convert.hg
def f(tag):
return tag.replace('some', 'other')
class source(hgext.convert.hg.mercurial_source):
def gettags(self):
return dict((f(tag), node)
for tag, node in in super(source, self).gettags().items())
def getfile(self, name, rev):
data, flags = super(source, self).getfile(name, rev)
if name == '.hgtags':
data = ''.join(l[:41] + f(l[41:]) + '\n' for l in data.splitlines())
return data, flags
hgext.convert.hg.mercurial_source = source
Before this patch, "hg outgoing" invokes "findcommonoutgoing()" not
only in "commands.outgoing()" but also in
"overrides.overrideoutgoing()" (via "getoutgoinglfiles()"), when
largefiles is enabled. The latter is redundant.
This patch uses "outgoinghooks" to avoid redundant outgoing check.
Newly introduced function "overrides.outgoinghook()" is registered
into "outgoinghooks" to get the result of outgoing check in
"commands.outgoing()".
It invokes "lfutil.getlfilestoupload()" directly with the result of
outgoing check to avoid redundant outgoing check in
"getoutgoinglfiles()": "sort()" is needed, because
"lfutil.getlfilestoupload()" doesn't sort the result of it.
This patch also omits "if toupload is None" ("No remote repo") case,
because failure of looking remote repository up should raise exception
in "commands.outgoing()" before invocation of "outgoinghooks".
Newly added "hg outgoing --large --graph" tests examine
"outgoinghooks" invocations in "hg outgoing --graph" code path.
Before this patch, "hg summary --remote --large" invokes
"findcommonoutgoing()" not only in "commands.summary()" but also in
"overrides.overridesummary()" (via "getoutgoinglfiles()"). The latter
is redundant.
This patch uses "summaryremotehooks" to avoid redundant outgoing check.
Newly introduced function "overrides.summaryremotehook()" is
registered into "summaryremotehooks" to get the result of outgoing
check in "commands.summary()".
It invokes "lfutil.getlfilestoupload()" directly with the result of
outgoing check to avoid redundant outgoing check in
"getoutgoinglfiles()".
Before this patch, "hg push" invokes "findcommonoutgoing()" not only
in "exchange.push()" but also in "lfilesrepo.push()", when largefiles
is enabled. The latter is redundant.
This patch registers own "prepushoutgoinghook" function into
"prepushoutgoinghooks" of "localrepository" to reuse
"findcommonoutgoing()" result.
"prepushoutgoinghook" omits "changelog.nodesbetween()" invocation,
because "findcommonoutgoing()" invocation in "exchange.push()" takes
"onlyheads" argument and it considers "nodesbetween()".
Before this patch, "overrides.getoutgoinglfiles()" (called by
"overrideoutgoing()" and "overridesummary()") and "lfilesrepo.push()"
implement similar logic to get outgoing largefiles separately.
This patch centralizes the logic to get outgoing largefiles in
"lfutil.getlfilestoupload()".
"lfutil.getlfilestoupload()" takes "addfunc" argument, because each
callers need different information (and it is useful for enhancement
in the future).
- "overrides.getoutgoinglfiles()" needs only filenames
- "lfilesrepo.push()" needs only hashes of largefiles
Previously, words like 'red' had to be protected by quotes before passing to
the label template function. Now, we add color effects to the symbol table so
that commands like,
$ hg log -r . -T "{label(red, node|short)}\n"
can work without the need for quoting.
Before this patch, manually edited commit message for "message"
command in histedit-ing is not saved into ".hg/last-message.txt" until
it is saved by "localrepository.savecommitmessage()" in
"localrepository.commit()".
This may lose such commit message, if unexpected exception is raised.
This patch saves manually edited commit message for "message" comand
in histedit-ing into ".hg/last-message.txt" just after user editing.
This is the simplest implementation to fix on stable. Editing and
saving commit message should be centralized into the framework of
"localrepository.commit()" with "editor" argument in the future.
This patch uses repository wrapping class for exception raising before
saving commit message in "localrepository.commit()" easily and
certainly, because such exception requires corner case condition.
Before this patch, "contrib/check-code.py" can't detect these
problems, because the regexp pattern to detect "% inside _()" doesn't
suppose the case that format string consists of multiple string
components concatenated implicitly or explicitly,
This patch does below for that regexp pattern to detect "% inside _()"
problems in such case.
- put "+" into separator part ("[ \t\n]") for explicit concatenation
("...." + "...." style)
- enclose "component and separator" part by "(?:....)+" for
concatenation itself ("...." "...." or "...." + "....")
Before this patch, "contrib/check-code.py" can't detect these
problems, because the regexp pattern to detect "% inside _()" doesn't
suppose the case that the format string and "%" aren't placed in the
same line.
This patch replaces "\s" in that regexp pattern with "[ \t\n]" to
detect "% inside _()" problems in such case.
"[\s\n]" can't be used in this purpose, because "\s" is automatically
replaced with "[ \t]" by "_preparepats()" and "\s" in "[]" causes
nested "[]" unexpectedly.
Since changeset a8955c4d9ef5, "reposetup()" of each extensions is
invoked only on repositories enabling corresponded extensions.
This causes that largefiles specific interactions between the
repository enabling largefiles locally and remote (wire) peer fail,
because there is no way to know whether largefiles is enabled on the
remote repository behind the wire peer, and largefiles specific
"wireproto functions" are not given to any wire peers.
To avoid this problem, largefiles should be enabled in wider scope
than each repositories (e.g. user-wide "${HOME}/.hgrc").
This patch introduces "wirepeersetupfuncs" to setup wire peer by
extensions already enabled. Functions registered into
"wirepeersetupfuncs" are invoked for all wire peers.
This patch uses plain list instead of "util.hooks" for
"wirepeersetupfuncs", because the former allows to control order of
function invocation by order of extension enabling: it may be useful
for workaround of problems with combination of enabled extensions
Before this patch, manually edited commit message for "fold" command
in histedit-ing is never saved into ".hg/last-message.txt", because it
uses "localrepository.commitctx()" instead of
"localrepository.commit()": saving into ".hg/last-message.txt" is
executed only in the latter.
This patch saves manually edited commit message for "fold" command in
histedit-ing into ".hg/last-message.txt" just after user editing.
This is the simplest implementation to fix on stable. Editing and
saving commit message for memctx should be centralized into the
framework like "localrepository.commit()" with "editor" argument or so
in the future.
Before this patch, manually edited commit message for "hg qfold -e"
isn't saved into ".hg/last-message.txt" until it is saved by
"localrepository.savecommitmessage()" in "localrepository.commit()".
This may lose such commit message, if unexpected exception is raised.
This patch saves manually edited commit message for "hg qfold -e" into
".hg/last-message.txt" just after user editing. This patch doesn't
save the message specified by -m/-l options as same as other commands.
This is the simplest implementation to fix on stable. Editing and
saving commit message should be centralized into the framework of
"localrepository.commit()" with "editor" argument in the future.
This patch uses repository wrapping class for exception raising before
saving commit message in "localrepository.commit()" easily and
certainly, because such exception requires corner case condition.
Before this patch, manually edited commit message for "hg qnew -e"
isn't saved into ".hg/last-message.txt" until it is saved by
"localrepository.savecommitmessage()" in "localrepository.commit()".
This may lose such commit message, if unexpected exception is raised.
This patch saves manually edited commit message for "hg qnew -e" into
".hg/last-message.txt" just after user editing. This patch doesn't
save the message specified by -m/-l options as same as other commands.
This is the simplest implementation to fix on stable. Editing and
saving commit message should be centralized into the framework of
"localrepository.commit()" with "editor" argument in the future.
This patch uses repository wrapping class for exception raising before
saving commit message in "localrepository.commit()" easily and
certainly, because such exception requires corner case condition.
Before this patch, "rebase --collapse --edit" without "--message" and
"--logfile" invokes editor twice unexpectedly:
1. explicit "ui.edit()" invocation in rebase extension itself
2. indirect invocation in "localrepository.commit()" with "editor =
commitforceeditor" assigned by "--edit" option
This patch uses indirect "commitforceeditor" invocation instead of
"ui.edit()" for "--collapse" without "--message" and "--logfile" to:
- suppress redundant the former invocation
- ensure editor invocation even when "--edit" is not specified
Changeset c84f81c3e120 (released with 2.8.1) fixed "recursively
evaluate string literals as templates" problem (issue4103) by
introducing "_evalifliteral()".
But some parts in template expressions below are still processed by
the combination of "compiletemplate()" and "runtemplate()", and may
cause same problem unexpectedly.
- 'init' and 'hang' of 'fill(text, width, init, hang)'
- 'expr' of 'sub(pat, repl, expr)'
- 'label' of 'label(label, expr)'
This patch processes them by "_evalifliteral()" instead of the
combination of "compiletemplate()" and "runtemplate()" to avoid
recursive evaluation of string literals completely.
Now "hg purge -p" commands avoids printiing duplication of filenames.
Second patch is the test coverage of first patch which tells that '-p'
does not depend on whether ui.verbose is configured or not,that means it
is independent of '-v'.
Record was changing the current directory to `repo.root` in order to be able to
feed `command.commit` file name relative to this `repo.root`. This is a bit
overkill and prevent an incoming fix to rebase. This would also break
multi-threaded usage.
Instead we just feed `command.commit` with absolute path name. works as well as
before but without chdir.
The fix for issue2653 broke the ability to map the default branch of a source
repository to a non-default named branch in the destination repository. Leave
the default behaviour as is, but allow the branch name "None" to be used to map
to a non-default named branch in the destination repository.
This is a gratuitous code move aimed at reducing the localrepo bloatness.
The method had few callers, not enough to be kept in local repo.
The peer API remains unchanged.
The `pushoperation` object contains strictly more data the arguments currently
passed to `localrepo.checkpush` we pass the new object instead. This function is
used by MQ to abort push that includes MQ changesets.
Note: extension that may use this function will have to align.
This should correct an earlier couple of bad merges (5433856b2558 and
596960a4ad0d, now pruned) that accidentally brought in a change that had
been marked obsolete (244ac996a821).
Before this patch, "localrepository.commit()" omits ".hgsubstate" from
"modified" (changes[0]) and "removed" (changes[2]) file list before
checking subrepositories, but leaves one in "added" (changes[1]) as it
is.
Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or
"removed" list forcibly, according to subrepository statuses.
If "added" contains ".hgsubstate", the committed context will contain
two ".hgsubstate" in its "files": one from "added" (not omitted one),
and another from "modified" or "removed" (newly added one).
How many times ".hgsubstate" appears in "files" changes node hash,
even though revision content is same, because node hash calculation
uses the specified "files" directly (without duplication check or so).
This means that node hash of committed revision changes according to
existence of ".hgsubstate" in "added" at "localrepository.commit()".
".hgsubstate" is treated as "added", not only in accidental cases, but
also in the case of "qpush" for the patch adding ".hgsubstate".
This patch omits ".hgsubstate" also from "added" files before checking
subrepositories. This patch also omits ".hgsubstate" exclusion in
"qnew"/"qrefresh" introduced by changeset bbb8109a634f, because this
patch makes them meaningless.
"hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t"
enhances checking unexpected multiple appearances of ".hgsubstate" in
"files" of created/refreshed MQ revisions.
When we specify a revision or a revset we just get the last element from the
list. For revsets this can lead to unintended effects where you specify a
revset like only() but instead histedit selects the highest revision in the
set as root. Therefore we should always use the lowest revision number as
root.
Some extensions set configuration settings that showed up in 'hg showconfig
--debug' with 'none' as source. That was confusing.
Instead, they will now tell which extension they come from.
This change tries to be consistent and specify a source everywhere - also where
it perhaps is less relevant.
Before this patch, even if specified file patterns and -I/-X options
cause listing ".hgsubstate" up in the target list, qnew/qrefresh put
".hgsubstate" into the target list individually and forcibly.
This changes how many times ".hgsubstate" appear in the target list
according to run-time conditions, and causes inconsistent node hash,
even though revision content is same, because node hash calculation
uses the specified target list directly (without duplication check or
so).
This patch always omits ".hgsubstate" from qnew/qrefresh target list
for consistent node hash.
This omitting doesn't miss including ".hgsubstate" changes, because:
- "localrepository.commit()" puts ".hgsubstate" into the target list
for "commitctx()" forcibly if needed
- "mq.putsubstate2changes()" puts ".hgsubstate" into the target list
for "patch.diff()" if it is not yet listed up
Before this patch, qnew puts updated subrepositories into target list
forcibly, if any of -I, -X or patterns are specified.
But this is meaningless and harmful, because:
- putting subrepositories into target list doesn't affect the result
of "localrepository.status()"
"dirstate.status()" invoked via "localrepository.status()" always
omits subrepositories from the result of it
- any -I/-X opts and empty "pats" causes unexpected failure
when any -I/-X opts are specified, "inclsubs" are always added to
"pats", even if "pats" is empty.
but this changes meaning of "pats" from "including all to be
included" to "including only listed subrepositories"
this may exclude ".hgsub" and cause unexpected exception raising
("can't commit subrepos without .hgsub" ).
- qnew at other than repository root (with -I, -X or any patterns)
causes unexpected failure
"scmutil.match()" treats pattern without syntax type as 'relpath'
type (= one rooted at cwd).
but qnew puts subrepository paths rooted at the repository root,
and it causes unexpected exception raising ("SUBREPO not under
root ROOT" in "pathutil.canonpath()"), if "hg qnew" is executed at
other than repository root with -I, -X or any patterns.
This patch omits meaningless and harmful putting subrepositories into
target list.
This omitting doesn't miss including updated subrepositories, because
subrepositories are specified to "scmutil.matchfiles()" directly, to
get "match" object for "localrepository.commit()".
This extension has always had correctness issues and has been
unmaintained for years. It is now removed in favor of the third-party
hgwatchman which is maintained and appears to be correct.
Users with inotify enabled in their config files will fall back to
standard status performance.
When the base is not found, we should not raise a traceback about a not defined
variable. This hides the real problem: the function rebasenode was (probably)
called wrong.
An AssertionError is raised to highlight that the caller of the function did
something wrong.
An alternative approach is to only assign None to the variable "base" and let
the merge mechanism raise an abort message. This was the behaviour for this
case before 544133bac670. But the only known case for this problem is when an
extension calls this function wrong. An AssertionError makes this clearer than
an abort message. When a different case is detected, the behaviour can be
improved then.
Subversion issues involving svn log such as 1e493b49245f can be tricky to
debug when it is run in an 'hg debugsvnlog' sub process. Debugging is simpler
when convert only uses one process.
With this change convert will invoke the svn log directly when setting
[convert]
svn.debugsvnlog = False
This is intentionally not documented.
It was hard for the user to know what was going on when unshelving - especially
if the user had to resolve conflicts and thus got to see the intermediate
states.
Seeing that pending changes was gone could scare the user, make him panic, and
do stuff that really made him lose data.
Merging (both when rebasing and with pending changes) also requires some
understanding of where in the process you are and what you are merging.
To help the user we now show a couple of status messages (when relevant):
temporarily committing pending changes (restore with 'hg unshelve --abort')
rebasing shelved changes
unshelve was quite verbose and it was hard for a user to follow what really was
going on. It ended up saying 'added 1 changesets' ... but the user just
expected and got pending changes and never saw any changeset.
The use of bundles is an implementation detail that we don't have to leak here.
Pulling is quite verbose, optimized for pulling many changesets from remote
repos - that is not the case here.
Instead, set the quiet flag when pulling the bundle - not only when temporarily
committing pending changes.
The 'finally' restore of ui.quiet is moved to the outer try/finally used for
locking.
The shelved changes _could_ perhaps be amended to the parent changeset but it
_is_ not the parent changeset. Using the description from the parent changeset
is thus wrong and confusing.
Instead, add a 'changes to' prefix.
Shelve do normally take a list of files or patterns to shelve and the command
summary should thus show [FILE]...
Note: --delete is a bit special and interpret the parameters as a list of
shelve names. This change makes that even less obvious from the help. Too bad
- we can't please everyone.
publicancestors returned the parents of the public ancestors ... and
changegroupsubset used the parents of these as base for the bundle. That gave
bundles with one layer of changesets more than necessary.
Mercurial tags can be local (tag -l, stored in .hg/localtags) or global (normal
tags, tracked in .hgtags) ... or extensions can add other kind of tags.
Convert would take all tags (except "tip"), not just the ones from .hgtags, and
put them into .hgtags.
Instead, convert only the global tags that come from .hgtags.
This patch also replaces "editor = False" by "editor =
cmdutil.getcommiteditor()", because:
- it allows to hook commit message determination easily, even in the
case without "--edit"
- it avoids regression (or additional care) around saving
"last-message.txt", even if MQ's "newcommit()" changes its
implementation logic from "localrepository.commit" to
"localrepository.commitctx" with "memctx" in the future
to save commit message into "last-messge.txt" with "memctx",
"editor" should be valid function.
This patch also replaces "editor = False" by "editor =
cmdutil.getcommiteditor()", because:
- the latter allows to hook commit message determination easily,
even in the case without "--edit"
- the latter can avoid regression (or additional care) around saving
"last-message.txt", even if MQ's "newcommit()" changes its
implementation logic from "localrepository.commit" to
"localrepository.commitctx" with "memctx" in the future
to save commit message into "last-messge.txt" with "memctx",
"editor" should be valid function.
This patch also enhances "test-rebase-scenario-global.t", because "hg
rebase" hasn't been explicitly tested around editor invocation and
"--edit" option.
In the other hand, this patch doesn't enhance tests in "hg rebase
--collapse" case, because it is already tested in
"test-rebase-collapse.t".
This omits (redundant) adding "\n' to "message", because:
- empty line is inserted by "commitforceeditor", if editor is invoked
- tail white-spaces are stripped at storing into chaneglog, otherwise
This patch also enhances "test-histedit-edit.t", because "hg histedit"
hasn't been explicitly tested around editor invocation and
"--continue" option.
Before this patch, "hg histedit" for "message" uses "ui.edit()" for
commit message editing.
It shows original commit message, but not detail about the target
revision: status of each modified/added/removed files, for example.
This patch uses the editor gotten by "getcommiteditor()" instead of
"ui.edit()" for "message"
In "test-histedit-edit.t", this patch omits "fixbundle" invocation,
because it prevents from confirming the "HG: added f" line in commit
message by filtering " added " lines.
Omiting "fixbundle" invocation causes that the exit code of "hg
histedit" appears as one of command line: in this case, "hg histedit"
is aborted by (expected) exception raising.
Previously, there was no way to rewrite tags on the fly while converting. Now,
we add similar logic to branchmap to provide a way to map old tags to new tags.
Currently, this is not enabled since there is not yet a command-line option.
Previously, when converting from a mercurial repo there would be an extraneous
commit at the end of the convert process that would rewrite tags. Now, we check
if there are any new tags before doing this rewriting.
Previously, the hg sink for puttags would just use one head for getting the old
tags which would sometimes lead to tags disappearing. Now, we iterate over all
heads and merge the results.
Upcoming patches will add new map files so we change the calling sequence of
checkrevformat so that error messages will let the user know which file has the
wrong rev format.
This is a simple find-and-replace strategy for matching anything in the
old description of a converted commit and, if that matched sha1 exists
in the mapping, replacing it with the new sha1.
In particular, this is helpful for descriptions that contain tags with
messages such as, "Added tag 1.0 for commit abcde1234567" which will now
be automatically converted.
Tests have been updated accordingly.
It looks like somewhere down the line, patch.diffopts changed the
names of the options that it recognises, but record.recordfunc wasn't
updated to the new names. Instead of trying to write down names at
all, we now use whatever names are provided in commands.diffwsopts and
pass that along to patch.diffopts, along with a couple of custom
options
The record extension is writing its own version of commands.diffwsopts
which is identical to commands.diffwsopts. Based on the principle that
code duplication increases maintenance burden, this patch removes
record's ad-hoc diffopts in favour of commands.diffwsopts
The largefile hashes are mostly an implementation detail, but they are "leaked"
in several places anyway, and showing the hashes is better than not giving the
user any information about the options in the prompt.
The hashes are long, but it is largefile hashes and it would thus be confusing
to shorten them.
Before it tried to explain the exact situation when merging moved largefiles.
That do not happen for normal merges and is not more relevant for largefiles
than for normal files. It is unneeded complexity - remove it.
Before this patch, transplant extension shows the list of available
responses by specific string, even though the prompt string passed to
"ui.promptchoice()" has enough (maybe i18n-ed) information.
This patch uses "ui.extractchoices()" to show the list of available
responses.
Before this patch, transplant extension uses "ui.prompt()" for
interactive transplant, and has to check whether user response
returned by "ui.prompt()" is valid or not in own code.
In addition to it, transplant extension uses response characters
(e.g. "y", "n", and so on) directly in own code, and this disallows to
use another response characters by translation, even though the help
shown by '?' typing is translatable.
This patch uses "ui.promptchoice()" instead of "ui.prompt()" to
resolve problems above.
Before this patch, record extension gets the list of available
responses from online help document of "hg record" in the tricky way,
even though the value passed to "ui.promptchoice()" has enough (maybe
i18n-ed) information.
This patch uses "ui.extractchoices()" to get the list of available
responses.
Before it just said 'nothing to rebase'.
Now 'if "base" is an empty set:
abort: empty "base" revision set - can't compute rebase set
If the set of changesets to rebase can't be found from "base", it will fail as
before but with more explanation of what the problem was.
The name of the "base" option is not obvious - it is more like "samples
identifying the branch to rebase". The error messages for problems with the
specified "base" value will use that term and might thus also not be obvious,
but at least they are consistent with the option name. The name "base" will not
be used if the base only was specified implicitly as the working directory
parent.
Before, it just said 'nothing to rebase' in this case. Now, it aborts
mentioning the reason: 'empty "source" revision set'.
Specifying revisions that cannot be rebased is a 'soft' error, but specifying
an empty set deserves an abort that explains exactly what the problem is.
Before, it just said 'nothing to rebase' in this case. Now, it aborts
mentioning the reason: 'empty "rev" revision set'.
Specifying revisions that cannot be rebased is a 'soft' error, but specifying
an empty set deserves an abort that explains exactly what the problem is.
Since the localrepositoyry.push() method in mercurial/localrepo.py is defined
this way:
def push(self, remote, force=False, revs=None, newbranch=False):
it is better for largefiles to call push() on the super class with proper
kwargs to respect the API.
This will avoid breaking other extensions overriding the push method this way:
def push(self, remote, force=False, **kwargs):
The -u flag didn't work when ui.username was not set and resulted in an
abort message. This was fixed by checking for the 'user' key in the opts
dictionary. If the key is present, the step causing the exception is not
executed.
Previously, unshelve would temporarily commit unknown files (via addremove) in
an attempt to allow unshelving into unknown files. This produced unexpected
results, like the file time stamp changing and a .i file being created.
This change makes it no longer use addremove. It ignores unknown files
completely. If an unshelve would overwrite an unknown file, the unknown file is
moved to *.orig
The shelve continue/abort format is changed, but it just removes stuff from the
end of the file, so it can still read the old format.
a8386b4c47b1 introduced splitstandin on all action filenames. It would however
crash on 'd' actions where the filename is None.
Fix that and add test coverage for that case.
The [x for y in l for x in y] syntax is nigh-incomprehensible, and this
is a particularly easy case to expand into a loop since there's no 'if'
condition in the list comprehension.
Previously, we'd acquire and release the wlock several times. This meant that
other hg processes could come in and change state. Instead of that, retain the
wlock for the entire duration of the strip.
Add a first check of the devices before collecting candidate files. This is
much quicker when big repos are on different devices.
Keep the existing check in prune. It checks for same device of the files. This
could probably be different in a special repo store (with symlinks).
Currently, histedit acquires and releases lock and wlock several times during
its run. This isn't great because it allows other hg processes to come in and
change state. With this fix, lock and wlock are acquired and released exactly
once.
The change to test-histedit-drop.t is a minor implementation one -- the cache
is still correctly invalidated, but it just happens a little later and only
gets printed out because of the unrelated --debug flag.
when evolve is enabled and a hidden obsolete changeset exists
in the repository, the strip during unshelve will fail due to
filtered revs. we use an unfiltered repository like to
repair.strip to strip the proper nodes.
An update would try to fetch any missing largefiles after having updated normal
files and standins. That could fail or be interrupted and would leave the
working directory in a state where the largefiles not only were missing but
also were scheduled for remove ... and where the old largefile was left in
place.
Instead we now remove old largefiles before starting to download and update
missing largefiles.
get_log started calling back with orig_paths=None on Fedora 20 with
subversion-1.8.3. That broke test-convert-svn-source.t .
There used to be some handling of that situation until d17c619e40d5 apparently
broke it. This patch restores what seems to be the most obvious handling of the
situation.
When running the unshare command, if there's other code that tries to use
the repo after the command is finished, it'll end up with a ui object for
repo.unfiltered(). This change fixes an erroneous call to repo.__init__()
that could be on the repoview proxy class--now it's always done on the
unfiltered repo.
Before this patch, transplant with "--merge" option fails with
traceback unexpectedly, if it causes pull from the source repository
on the local host.
"discovery.findcommonincoming()" invokes "capable()" method on the
object given from "localrepository.pull()", but it is
"localrepository" object in this case and doesn't have such method.
This patch uses peer object of source repository as "remote" argument
for "localrepository.pull()" invocation like other invocations of it
in transplant.py.
Rebasing with --collapse would leave the working copy on the parent of the
collapsed commit, instead of on the collapsed commit. This fixes that. Also
fixes a few tests that already covered this area but had bad data.
This also fixes issue3716 where bookmarks are not kept across rebases with
--collapse. I updated the test to cover that case as well.
When aborting a rebase where tip-1 is public, rebase would fail to undo the merge
state. This caused unexpected dirstate parents and also caused unshelve to
become unabortable (since it uses rebase under the hood).
The problem was that rebase uses -2 as a marker rev, and when it checked for
immutableness during the abort, -2 got resolved to the second to last entry in
the phase cache.
Adds a test for the fix. Add exception to phase code to prevent this in the
future.
Fix test-check-pyflakes.t error after 98058c06ff6b.
This patch replaces "readshelvedfiles()" invocation by
"shelvedfile().exists()" check and aborting, because it is required
only to ensure that shelved changes corresponded to specified name
exist after invocation.
This patch also remove definition of "readshelvedfiles()" itself,
because it is invoked only from the line removed by this patch.
Prior this changeset, rebasing a merge whose first parent was not in
the rebase lead to wrong and highly conflicting merge. See the in-line
comment for details.
Test have been updated with the data provided by the reported.
Prompts like
foo has been turned into a largefile
use (l)argefile or keep as (n)ormal file?
was not as clear as the usual prompts that use 'remote' or 'local' to explain
what happened on which side ... especially not when used to the normal prompts.
"as" could also indicate that it would be possible to take the content of the
largefile and somehow put it into the normal file. It could make it more clear
that it was a choice between one side or the other.
For consistency we will now phrase it like:
remote turned local normal file f into a largefile
use (l)argefile or keep (n)ormal file?
This patch removes code paths in "shelvedfile.opener()", because:
- explicit "vfs.mkdir()" invocation is useless
"vfs.__call__()" for modes other than "read" creates parent
directory of target file automatically by "util.ensuredirs()".
- mode checking in "except IOError" code path is useless
ENOENT occurs only for "read" mode, because target file is
created forcibly for other modes.
- there is no explicit "return" statement in the code path for
"except IOError" if "mode[0] in 'wa'"
this is incorrect, because None may be returnd unexpectedly,
even though it seems the EEXIST case in the directory creation
race for ".hg/shelved" and is very rare.
this directory creation race is also treated in
"util.ensuredirs()".
Before this patch, commit is allowed even while unshelve is in
progress.
In the other hand, "hg unshelve --abort" and "hg unshelve --continue"
check whether parent revisions of the working directory have changed
or not since last "hg unshelve", and abort without clearing state for
unshelve in progress if they have.
This causes that accidental commit makes clearing state for unshelve
difficult in ordinary ways.
This patch disallows commit while unshelve is in progress for
consistency.
Previously, shelve used merge to unshelve things. This meant that if you shelved
changes on one branch, then unshelved on another, all the changes from the first
branch would be present in the second branch, and not just the shelved changes.
The fix is to use rebase to pick the shelve commit off the original branch and
place it on top of the new branch. This means only the shelved changes are
brought across.
This has the side effect of fixing several other issues in shelve:
- you can now unshelve into a file that already has pending changes
- unshelve a mv/cp now has the correct dirstate value (A instead of M)
- you can now unshelve to an ancestor of the shelve
- unshelve now no longer deletes untracked .orig files
Updates tests and adds a new one to cover the issue. The test changes fall into
a few categories:
- I removed some excess output
- The --continue/--abort state is a little different, so the parents and
dirstate needed updating
- Removed some untracked files at certain points that cluttered the output
On Windows, only double quotation mark can quote command line
arguments.
So, this patch uses double quotation mark to quote command line
arguments in all examples of online help document.
We used to get like:
$ hg up -r 2
foo has been turned into a normal file
keep as (l)argefile or use (n)ormal file? l
getting changed largefiles
0 largefiles updated, 0 removed
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
$ cat foo
cat: foo: No such file or directory
[1]
- which both asked the wrong question and did the wrong thing.
Instead, skip this conflict resolution when the local conflicting file has been
scheduled for removal and there thus is no conflict.
If paging is configured for a command all it's internal defined aliases
will be paged as well. This will make attend=log cause 'hg history'
to run the pager. However custom aliases will not be paged by default.
Before this patch, each feature setup functions for localrepository
class should examine whether corresponding extension is enabled or not
by themselves.
This patch invokes only feature setup functions defined in module of
enabled extensions, and it makes implementation of feature setup
functions easier and simpler.
Prior to this changeset, rebase always left the working directory as a parent of
the last rebased changeset. The is dubious when, before the rebase, the working
directory was not a parent of the tip most rebased changeset.
With this changeset, we move the working directory back to its original parent.
If the original parent was rebased, we use it's successors.
This is a step toward solving issue3813 (rebase loses active bookmark if it's
not on a head)
