Tue, 09 Dec 2014 14:18:31 -0800 merge: move dr/rd warning messages out of applyupdates()
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.
Fri, 05 Dec 2014 16:13:26 -0800 merge: don't report progress for dr/rd actions
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.
Wed, 10 Dec 2014 10:32:51 +0100 subrepo: add partial diff support for git subrepos
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.
Wed, 10 Dec 2014 08:41:21 +0100 subrepo: extend git version check to 3 digits
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.
Wed, 10 Dec 2014 08:33:03 +0100 subrepo: move git version check into a separate method
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.
Thu, 11 Oct 2012 23:22:02 +0200 rebase: show a note for updated mq patches
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.
Wed, 10 Dec 2014 06:20:35 +0100 rebase: improve debug messages while processing the list of rebases
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
Wed, 10 Dec 2014 06:20:35 +0100 rebase: show warning when rebase creates no changes to commit
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
Tue, 09 Dec 2014 03:45:26 +0100 rebase: show more useful status information while rebasing
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.
Sun, 07 Dec 2014 20:04:45 +0100 tests: make 'saved backup' globbing less narrow in rebase tests
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).
Tue, 09 Dec 2014 03:37:06 +0100 tests: stabilise mq rebase tests
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.
Tue, 09 Dec 2014 14:45:12 -0500 test-graft: use strip extension instead of mq extension
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.
Thu, 04 Dec 2014 13:52:46 -0800 transaction: remove the 'onabort' mechanism
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.
Thu, 04 Dec 2014 13:51:41 -0800 transaction: remove the redundant 'onclose' mechanism
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.
Thu, 04 Dec 2014 16:35:03 -0800 fncache: document the fact fncache is outdate at hook run time
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.
Thu, 04 Dec 2014 13:49:45 -0800 fncache: drop dedicated 'onclose' function in favor of 'tr.addfinalize'
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.
Tue, 09 Dec 2014 13:32:19 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Tue, 09 Dec 2014 13:32:19 -0600] rev 23509
merge with stable
Tue, 09 Dec 2014 12:39:23 -0600 graft: drop cset description from empty commit message
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.
Tue, 09 Dec 2014 03:38:23 +0100 graft: show hashes in user-facing messages
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.
Tue, 09 Dec 2014 03:38:23 +0100 graft: give helpful warning for empty grafts
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)
Tue, 09 Dec 2014 03:38:23 +0100 graft: show more useful status information while grafting
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.
Tue, 09 Dec 2014 03:37:55 +0100 tests: test coverage for empty graft
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.
Sun, 07 Dec 2014 10:54:29 -0500 largefiles: drop the unfiltered repo usage in overridepurge()
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.
Sun, 07 Dec 2014 10:52:56 -0500 repoview: allow methods on the proxy class to be replaced
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().
Mon, 08 Dec 2014 15:41:54 -0800 log: fix log revset instability stable
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.
Fri, 05 Dec 2014 14:27:32 -0800 log: fix log -f slow path to actually follow history stable
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.
Wed, 26 Nov 2014 23:23:33 -0800 obsstore: cache size computation for fm1 node
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.
Wed, 26 Nov 2014 23:21:20 -0800 obsstore: prefetch struct.calcsize
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.
Wed, 26 Nov 2014 16:58:31 -0800 obsstore: disable garbage collection during initialization (issue4456)
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.
Thu, 04 Dec 2014 05:43:15 -0800 dirstate: use the 'nogc' decorator
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.
Thu, 04 Dec 2014 05:43:40 -0800 util: add a 'nogc' decorator to disable the garbage collection
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.
Fri, 05 Dec 2014 22:58:02 -0500 generate-working-copy-states: open() in binary mode when writing content
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
Fri, 05 Dec 2014 16:45:52 -0800 largefiles: don't use 'r' action for standin that doesn't exist
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.
Fri, 05 Dec 2014 16:51:37 -0800 largefiles: don't use 'r' action for normal file that doesn't exist
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.
Tue, 02 Dec 2014 12:23:12 -0800 rebase: handle revtodo as a special value when storing/restoring state
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.
Tue, 02 Dec 2014 09:46:20 -0800 rebase: add a 'revtodo' constant
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.
Thu, 04 Dec 2014 07:03:02 -0800 rebase: use '>= 0' to know is a revision was rebased
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.
Tue, 02 Dec 2014 17:35:21 -0800 patchbomb: introduce a 'patchbomb.confirm' option
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.
Tue, 02 Dec 2014 17:24:52 -0800 patchbomb: add a 'patchbomb.intro' option
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.
Tue, 02 Dec 2014 16:51:32 -0800 patchbomb: extract 'getoutgoing' closure into its own function
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.
Thu, 20 Nov 2014 16:27:55 -0800 perf: add a perfloadmarkers command
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.
Wed, 19 Nov 2014 03:38:51 +0100 rebase: move base calculation from rebasenode() to defineparents()
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.
Fri, 05 Dec 2014 10:53:25 -0800 largefiles: remove redundant checks for false modify/delete conflicts
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().
Wed, 03 Dec 2014 14:03:20 -0800 merge: make 'keep' message more descriptive
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.
Thu, 04 Dec 2014 23:08:27 -0500 addremove: restore the relative path printing when files are named
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.
Thu, 04 Dec 2014 23:04:55 -0500 match: introduce uipath() to properly style a file path
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.
Fri, 05 Dec 2014 12:10:56 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 05 Dec 2014 12:10:56 -0600] rev 23479
merge with stable
Sun, 16 Nov 2014 23:41:44 -0800 update: don't overwrite untracked ignored files on update 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.
Tue, 02 Dec 2014 17:11:01 -0800 update: add tests for untracked local file stable
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.
Wed, 03 Dec 2014 11:02:52 -0800 merge: don't overwrite conflicting file in locally renamed directory
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.
Wed, 03 Dec 2014 10:56:07 -0800 merge: don't ignore conflicting file in remote renamed directory
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.
Sun, 23 Nov 2014 15:08:50 -0800 merge: duplicate 'if f in copied' into each branch
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
Sun, 23 Nov 2014 14:09:10 -0800 merge: branch code into {n1 and n2, n1, n2} top-level cases
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.
Tue, 02 Dec 2014 16:39:59 -0800 update: remove redundant and misplaced merge tests
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.
Fri, 21 Nov 2014 13:02:45 -0800 largefiles: use clearer debug messages in actions
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.
Fri, 21 Nov 2014 11:44:57 -0800 largefiles: don't clobber merge action message with user message
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.
(0) -10000 -3000 -1000 -300 -100 -56 +56 +100 +300 +1000 +3000 +10000 tip