Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 14:18:31 -0800] rev 23525
merge: move dr/rd warning messages out of applyupdates()
As preparation for making 'dr' and 'rd' actions no longer actions,
move the reporting from applyupdates() to its caller update(). This
way we won't have to pass additonal arguments to applyupdates() when
they are no longer actions. Also, the warnings are equally unrelated
to applyupdates() as they are to recordupdates(), as they don't result
in any changes to either the working copy or the dirstate.
See earlier patch for additional motivation.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Dec 2014 16:13:26 -0800] rev 23524
merge: don't report progress for dr/rd actions
It is easier to reason about certain algorithms in terms of a
file->action mapping than the current action->list-of-files. Bid merge
is already written this way (but with a list of actions per file), and
largefiles' overridecalculateupdates() will also benefit. However,
that requires us to have at most one action per file. That requirement
is currently violated by 'dr' (divergent rename) and 'rd' (rename and
delete) actions, which can exist for the same file as some other
action.
These actions are only used for displaying warnings to the user; they
don't change anything in the working copy or the dirstate. In this
way, they are similar to the 'k' (keep) action. However, they are even
less action-like than 'k' is: 'k' at least describes what to do with
the file ("do nothing"), while 'dr' and 'rd' or only annotations for
files for which there may exist other, "real" actions.
As a first step towards separating these acitons out, stop including
them in the progress output, just like we already exclude the 'k'
action.
Mathias De Maré <mathias.demare@gmail.com> [Wed, 10 Dec 2014 10:32:51 +0100] rev 23523
subrepo: add partial diff support for git subrepos
So far, git subrepositories were silently ignored for diffs.
This patch adds support for git subrepositories,
with the remark that --include and --exclude are not supported.
If --include or --exclude are used, the subrepo is ignored.
Mathias De Maré <mathias.demare@gmail.com> [Wed, 10 Dec 2014 08:41:21 +0100] rev 23522
subrepo: extend git version check to 3 digits
This allows more flexibility when a version check is required.
Some git features are introduced in a version where only
the 3rd digit changes.
Mathias De Maré <mathias.demare@gmail.com> [Wed, 10 Dec 2014 08:33:03 +0100] rev 23521
subrepo: move git version check into a separate method
This allows checking the git version in other methods,
instead of only being able to check if the version is ok or not.
Mads Kiilerich <mads@kiilerich.com> [Thu, 11 Oct 2012 23:22:02 +0200] rev 23520
rebase: show a note for updated mq patches
It deserves more than a debug message. Show a note like:
updating mq patch p0.patch to 5:
9ecc820b1737
The message could also refer to "qrefresh" instead. Same same.
Mads Kiilerich <madski@unity3d.com> [Wed, 10 Dec 2014 06:20:35 +0100] rev 23519
rebase: improve debug messages while processing the list of rebases
Mads Kiilerich <madski@unity3d.com> [Wed, 10 Dec 2014 06:20:35 +0100] rev 23518
rebase: show warning when rebase creates no changes to commit
Similar to graft:
note: rebase of 6:
eea13746799a created no changes to commit
Mads Kiilerich <madski@unity3d.com> [Tue, 09 Dec 2014 03:45:26 +0100] rev 23517
rebase: show more useful status information while rebasing
Show status messages while rebasing, similar to what graft do:
rebasing 12:
2647734878ef "fork" (tip)
This gives more context for the user when resolving conflicts.
Mads Kiilerich <madski@unity3d.com> [Sun, 07 Dec 2014 20:04:45 +0100] rev 23516
tests: make 'saved backup' globbing less narrow in rebase tests
Globbing the hash made it harder to maintain tests with run-tests -i when it
was so far by the generated test output.
The hashes are stable and we just need to add a (glob).
Mads Kiilerich <madski@unity3d.com> [Tue, 09 Dec 2014 03:37:06 +0100] rev 23515
tests: stabilise mq rebase tests
Prepare for including hashes in output ... and less globbing make the tests
easier to update.
Augie Fackler <raf@durin42.com> [Tue, 09 Dec 2014 14:45:12 -0500] rev 23514
test-graft: use strip extension instead of mq extension
It only needs strip, no reason to load all of mq.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Dec 2014 13:52:46 -0800] rev 23513
transaction: remove the 'onabort' mechanism
It has no known users. If someones needs similar functionality, a new 'addabort'
method similar to 'addfinalize' should be added.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Dec 2014 13:51:41 -0800] rev 23512
transaction: remove the redundant 'onclose' mechanism
It is superseded by the 'addfinalize' function and all its user have been
migrated.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Dec 2014 16:35:03 -0800] rev 23511
fncache: document the fact fncache is outdate at hook run time
Using 'addfinalize' to generate 'fncache' means that no pending version of the
file will be generated for the hooks. We would have to use the
'addfilegenerator' method to get such result. However the 'fncachevfs' (who
decide that a write is necessary) have no access to the transaction to register
such file generation at add time. Having the transaction accessible to the 'vfs'
is too much trouble for no benefit. This outdated 'fncache' file at hook time is
not expected to be an issue.
The previous move from 'onclose' to 'addfinalize' had no impact on this timing.
I'm documenting it now because I looked at it.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Dec 2014 13:49:45 -0800] rev 23510
fncache: drop dedicated 'onclose' function in favor of 'tr.addfinalize'
Now that we have a shiny generic mechanism, we can use it.
Matt Mackall <mpm@selenic.com> [Tue, 09 Dec 2014 13:32:19 -0600] rev 23509
merge with stable
Matt Mackall <mpm@selenic.com> [Tue, 09 Dec 2014 12:39:23 -0600] rev 23508
graft: drop cset description from empty commit message
This is either already redundant in the output or too verbose in quiet
mode.
Mads Kiilerich <madski@unity3d.com> [Tue, 09 Dec 2014 03:38:23 +0100] rev 23507
graft: show hashes in user-facing messages
Graft was in various places just showing the revision number in status
messges. Instead, also show the stable and more useful short hash.
Mads Kiilerich <madski@unity3d.com> [Tue, 09 Dec 2014 03:38:23 +0100] rev 23506
graft: give helpful warning for empty grafts
It was just showing a status message with the internal revision number.
Instead, show a warning like
note: graft of 27:
3aaa8b6725f0 "28" created no changes to commit
(message tweaked in-flight by mpm)
Mads Kiilerich <madski@unity3d.com> [Tue, 09 Dec 2014 03:38:23 +0100] rev 23505
graft: show more useful status information while grafting
Show status messages with first line of commit description and names, like
grafting 12:
2647734878ef "fork" (tip)
This gives more context for the user when resolving conflicts.
Mads Kiilerich <madski@unity3d.com> [Tue, 09 Dec 2014 03:37:55 +0100] rev 23504
tests: test coverage for empty graft
A future change will add a warning to the quiet rebase.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 07 Dec 2014 10:54:29 -0500] rev 23503
largefiles: drop the unfiltered repo usage in overridepurge()
Now that repoview supports replacing methods, we don't need this hack.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 07 Dec 2014 10:52:56 -0500] rev 23502
repoview: allow methods on the proxy class to be replaced
It doesn't seem to be a common idiom for repo instances, but the status() method
is replaced in largefiles' purge() override. Since __setattr__ is implemented
in repoview to setattr() on the unfiltered repo, the replacement method wouldn't
get called unless it was invoked with the unfiltered repo, because the filtered
repo remains unchanged.
Since this doesn't seem to be commonly used, I didn't bother to filter out
methods that perhaps shouldn't be replaced, such as changelog().
Durham Goode <durham@fb.com> [Mon, 08 Dec 2014 15:41:54 -0800] rev 23501
log: fix log revset instability
The log/graphlog revset was not producing stable results since it was
iterating over a dict. Now we sort before iterating to guarantee a fixed order.
This fixes some potential flakiness in the tests.
Durham Goode <durham@fb.com> [Fri, 05 Dec 2014 14:27:32 -0800] rev 23500
log: fix log -f slow path to actually follow history
The revset created when -f was used with a slow path (for patterns and
directories) did not actually contain any logic to enforce follow. Instead it
was depending on the passed in subset to already be limited (which was limited
to :. but not ::.). This fixes it by adding a '& ::.' to any -f log revset.
hg log -f <file> is still broken, in that it can return results that aren't
actually ancestors of the current file, but fixing that has major perf
implications, so we'll deal with it later.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 26 Nov 2014 23:23:33 -0800] rev 23499
obsstore: cache size computation for fm1 node
We have two different types of node type (sha1 and sha256, only sha1 is used
now) and therefor different sizes for them. We now compute the value once
instead of redoing the computation every loop. This has no visible performance
impact.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 26 Nov 2014 23:21:20 -0800] rev 23498
obsstore: prefetch struct.calcsize
This function is widely used and worth but be at module level. No specific
performance boost is visible, but this is more consistent.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 26 Nov 2014 16:58:31 -0800] rev 23497
obsstore: disable garbage collection during initialization (
issue4456)
Python garbage collection is triggered by container creation. So code that
creates a lot of tuples tends to trigger GC a lot. We disable the gc during
obsolescence marker parsing and associated initialization. This provides an
interesting speedup (25%).
Load marker function on my 58758 markers repo:
before: 0.468247 seconds
after: 0.344362 seconds
The benefit is a bit less visible overall. With python2.6 on my system I see:
after: 0.60
before: 0.53
The difference is probably explained by the delaying of a costly GC. (but there
is still a win). Marking involved tuples, lists and dicts as ignorable by the
garbage collector should give us more benefit. But this is another adventure.
Thanks goes to Siddharth Agarwal for the lead.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Dec 2014 05:43:15 -0800] rev 23496
dirstate: use the 'nogc' decorator
Now that we have a generic way to disable the gc, we use it. however, we have too
use it in a baroque way. See inline comment for details.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Dec 2014 05:43:40 -0800] rev 23495
util: add a 'nogc' decorator to disable the garbage collection
Garbage collection behave pathologically when creating a lot of containers. As
we do that more than once it become sensible to have a decorator for it. See
inline documentation for details.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 05 Dec 2014 22:58:02 -0500] rev 23494
generate-working-copy-states: open() in binary mode when writing content
This avoids changes to the hashes on Windows in test-merge-force.t like so:
@@ -594,12 +594,12 @@
content2
M missing_content2_content3_content4-tracked
- <<<<<<< local:
443153eb5b88 - test: local\r (esc)
- content4
- ||||||| base
- =======
- content2
- >>>>>>> other:
9b2ccd328a08 - test: remote\r (esc)
+ <<<<<<< local:
0447570f1af6 - test: local
+ content4
+ ||||||| base
+ =======
+ content2
+ >>>>>>> other:
85100b8c675b - test: remote
missing_content2_content3_content4-tracked.orig:
content4
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Dec 2014 16:45:52 -0800] rev 23493
largefiles: don't use 'r' action for standin that doesn't exist
When merging and the remote has turned a normal file into a largefile
and the user chooses to keep the local largefile, we use the 'r'
action for the remote largefile standin. This is wrong, since that
file does not exist in the parent of the working copy. Use 'k', which
does nothing but debug logging, instead.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Dec 2014 16:51:37 -0800] rev 23492
largefiles: don't use 'r' action for normal file that doesn't exist
When merging and the remote has turned a largefile into a normal file
and the user chooses to keep the local largefile, we use the 'r'
action for the remote normal file. This is wrong, since that file does
not exist in the parent of the working copy. Use 'k', which does
nothing but debug logging, instead.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 02 Dec 2014 12:23:12 -0800] rev 23491
rebase: handle revtodo as a special value when storing/restoring state
Revtodo happens to share its value with nullrev, but this is an implementation
details, so we move away from it.
After this changeset one can successfully change the values for all
the constants and the tests still pass, but doing so would require more
refactoring if we want to avoid breaking backward compatibility on the
state file.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 02 Dec 2014 09:46:20 -0800] rev 23490
rebase: add a 'revtodo' constant
The state mapping is using '-1' to mark revisions that have not been
rebased yet. We introduce and use a constant for that purpose. This
will help emphasize the fact the value means something other than
nullrev.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Dec 2014 07:03:02 -0800] rev 23489
rebase: use '>= 0' to know is a revision was rebased
The fact that the state for "not yet rebased" is -1 is an implementation
details. So we change the comparisons to some semantically more correct.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 02 Dec 2014 17:35:21 -0800] rev 23488
patchbomb: introduce a 'patchbomb.confirm' option
When set to true, this option will make patchbomb always ask for confirmation
before sending the email. Confirmation is a powerful way to prevent stupid
mistakes when the sending patches.
This should let me get rid of my global alias adding
--confirm to hg email.
I know that some people may get bitten when moving from a machine with confirm
configured to a machine where it is not, but I think it is worth the risk.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 02 Dec 2014 17:24:52 -0800] rev 23487
patchbomb: add a 'patchbomb.intro' option
This option allows the user to control the default behavior for
including an introduction message. This avoids having to tirelessly
skip the intro for people contributing to Mercurial.
The three possibles values are:
- always,
- auto (default, current behavior),
- never.
I was thinking of ("true", "false", "") (empty value being auto) but I ruled it
out as too confusing.
This new config option reuses the pre-existing 'patchbomb' section.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 02 Dec 2014 16:51:32 -0800] rev 23486
patchbomb: extract 'getoutgoing' closure into its own function
This continues my crusade against closure complication.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 20 Nov 2014 16:27:55 -0800] rev 23485
perf: add a perfloadmarkers command
It is used to benchmark the obsstore initialization time.
Mads Kiilerich <madski@unity3d.com> [Wed, 19 Nov 2014 03:38:51 +0100] rev 23484
rebase: move base calculation from rebasenode() to defineparents()
We want to collect all calculation in one place.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Dec 2014 10:53:25 -0800] rev 23483
largefiles: remove redundant checks for false modify/delete conflicts
In
a34a99181f36 (largefiles: don't show largefile/normal prompts if
one side is unchanged, 2014-12-01), overridecalculateupdates() started
checking for false modify/delete conflicts in large files and their
standins. Then, in the very next changeset,
902554884335 (merge:
before cd/dc prompt, check that changed side really changed,
2014-12-01), calculateupdates() itself started checking for false
modify/delete conflicts in all files. Since "large files and their
standins" is a subset of "all files", we can now drop the checks in
overridecalculateupdates().
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Dec 2014 14:03:20 -0800] rev 23482
merge: make 'keep' message more descriptive
Most merge action messages don't describe the action itself, they
describe the reason the action was taken. The only exeption is the 'k'
action, for which the message is just "keep" and instead there is a
code comment folling it that says "remote unchanged". Let's move that
comment into the merge action message.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 04 Dec 2014 23:08:27 -0500] rev 23481
addremove: restore the relative path printing when files are named
This fixes the previously mentioned issue with
3778884197f0, and undoes its
corresponding test change.
The test change demonstrates the correctness when a file is specified (i.e. the
glob is required on Windows because relative paths use '\' and absolute paths
use '/'). It is admittedly very subtle, but there will be a more robust test in
the addremove -S v3 series.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 04 Dec 2014 23:04:55 -0500] rev 23480
match: introduce uipath() to properly style a file path
Several methods print files relative to the repo root, unless files are named on
the command line, in which case they are printed relative to cwd. Since the
check relies on the 'pats' parameter, which needs to be replaced by a matcher
when adding subrepo support, this logic gets folded into the matcher to tidy up
the callers.
Prior to
3778884197f0, this style decision was based off of whether or not the
'pats' list was empty. That change altered the check to test match.anypats()
instead, in order to make paths printed consistent when -I/-X is specified.
That however, changed the style when a file is given to the command. So now we
test the pattern list to get the old behavior for files, as well as test -I/-X
to get the consistency for patterns.
Matt Mackall <mpm@selenic.com> [Fri, 05 Dec 2014 12:10:56 -0600] rev 23479
merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Sun, 16 Nov 2014 23:41:44 -0800] rev 23478
update: don't overwrite untracked ignored files on update
When looking for untracked files that would conflict with a tracked
file in the target revision (or the remote side of a merge), we
explcitly exclude ignored files. The code was added in
7e30f5f2285f
(merge: refactor unknown file conflict checking, 2012-02-09), but it
seems like only unknown, not ignored, files were considered since the
beginning of time.
Although ignored files are mostly build outputs and backup files, we
should still not overwrite them. Fix by simply removing the explicit
check.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 02 Dec 2014 17:11:01 -0800] rev 23477
update: add tests for untracked local file
We don't seem to have any tests for updating to another revision when
there are untracked files on the local side that conflict with the
those on the remote side, so let's add tests. This shows how we
overwrite untracked ignored files when updating to a revision that
tracks the file.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Dec 2014 11:02:52 -0800] rev 23476
merge: don't overwrite conflicting file in locally renamed directory
When the local side has renamed a directory from a/ to b/ and added a
file b/c in it, and the remote side has added a file a/c, we end up
overwriting the local file b/c with the contents of remote file
a/c. Add a check for this case and use the merge ('m') action in this
case instead of the directory rename get ('dg') action.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Dec 2014 10:56:07 -0800] rev 23475
merge: don't ignore conflicting file in remote renamed directory
When the remote side has renamed a directory from a/ to b/ and added a
file b/c in it, and the local side has added a file a/c, we end up
moving a/c to b/c without considering the remote version of b/c. Add a
check for this case and use the merge ('m') action in this case
instead of the directory rename ('dm') action.
Martin von Zweigbergk <martinvonz@google.com> [Sun, 23 Nov 2014 15:08:50 -0800] rev 23474
merge: duplicate 'if f in copied' into each branch
Martin von Zweigbergk <martinvonz@google.com> [Sun, 23 Nov 2014 14:09:10 -0800] rev 23473
merge: branch code into {n1 and n2, n1, n2} top-level cases
There are three high-level cases that are of interest in
manifestmerge(): 1) The file exists on both sides, 2) The file exists
only on the local side, and 3) The file exists only on the remote
side. Let's make this clearer in the code.
The 'if f in copied' case will be broken up into the two applicable
branches in the next patch.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 02 Dec 2014 16:39:59 -0800] rev 23472
update: remove redundant and misplaced merge tests
The "nothing to merge" case is covered by test-merge-default.t.
The "uncommitted changes" case is covered by test-merge1.t (and
others).
The "merge -f" case is covered by test-merge-force.t.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 21 Nov 2014 13:02:45 -0800] rev 23471
largefiles: use clearer debug messages in actions
In overridecalculateupdates(), 'g' (get) actions may be converted into
other actions. In most of these cases, it does not make sense to keep
the action's message. For example, 'remote created' does not make
sense for an 'r' (remove) action.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 21 Nov 2014 11:44:57 -0800] rev 23470
largefiles: don't clobber merge action message with user message
The message in the action is used for debugging and should not be the
same as the question presented to the user. Use a different variable
for the user message, so the 'msg' variable already in scope does not
get overwritten.