- Dec 13, 2014
-
-
Kyle Lippincott authored
-
- Dec 12, 2014
-
-
Siddharth Agarwal authored
Without this patch, if the server sets preferuncompressed, there's no way for clients to override that and force a non-streaming clone. With this patch, we extend the meaning of --pull to also override preferuncompressed and force a non-streaming clone.
-
Siddharth Agarwal authored
In an upcoming patch we'll differentiate between the two in localrepo.
-
- Nov 14, 2014
-
-
Martin von Zweigbergk authored
When there are multiple common ancestors, we should check for case collisions only on the resulting actions after bid merge has run. To do this, move the code until after bid merge. Move it past _resolvetrivial() too, since that might update actions. If the remote changed a file and then reverted the change, while the local side deleted the file and created a new file with a name that case-folds like the old file, we should fail before this patch but not after. Although the changes to the actions caused by _forgetremoved() should have no effect on case collisions, move it after that, too, so the next person reading the code won't have to think about it. Moving it past these blocks of code takes it to the end of calculateupdates(), so let's even move it outside of the method, so we also check collisions in actions produced by extensions overriding the method.
-
- Apr 17, 2014
-
-
Mads Kiilerich authored
-
- Dec 13, 2014
-
-
Mathias De Maré authored
The output of 'git diff --stat' changed in git 1.7.10 and 1.7.11. To ensure the tests work with earlier versions of git as well, the output is now wrapped with a whitespace regex.
-
- Dec 12, 2014
-
-
Martin von Zweigbergk authored
By moving the cd/dc prompts out of calculateupdates(), we let largefiles' overridecalculateupdates() so the unresolved values (i.e. 'cd' or 'dc' rather than 'g', 'r', 'a' and missing). This allows overridecalculateupdates() to ask the user whether to keep the normal file or the largefile before the user gets the cd/dc prompt. Whichever answer the user gives, we make overridecalculateupdates() replace 'cd' or 'dc' action, saving the user one annoying (and less clear) question.
-
- Dec 01, 2014
-
-
Matt Harbison authored
Since addremove on the top of a directory tree will recursively handle sub directories, it should be the same with deep subrepos, once the user has explicitly asked to process a subrepo. This really only has an effect when a path that is a subrepo (or is in a subrepo) is given, since -S causes all subrepos to be processed already. An addremove without a path that crosses into a subrepo, will still not enter any subrepos, per backward compatibility rules.
-
- Nov 10, 2014
-
-
Matt Harbison authored
Git and svn subrepos are currently not supported.
-
- Nov 25, 2014
-
-
Matt Harbison authored
Git and svn subrepos are currently not supported. It doesn't look like git or svn have these commands natively, so that's an area for a git or svn expert.
-
Matt Harbison authored
The recursive addremove operation occurs completely before the first subrepo is committed. Only hg subrepos support the addremove operation at the moment- svn and git subrepos will warn and abort the commit.
-
- Nov 26, 2014
-
-
Matt Harbison authored
This will be used in the next patch to print a warning from the base class. It seems better than having to explicitly pass it to a new method, since a lot of existing methods also require it.
-
Matt Harbison authored
This will be required when subrepo support is added, in order to ensure consistent commits when a subrepo flavor doesn't support addremove.
-
Matt Harbison authored
It looks like a bad path is the only mode of failure for addremove. This warning is probably useful for the standalone command, but more important for 'commit -A'. That command doesn't currently abort if the addremove fails, but it will be made to do so prior to adding subrepo support, since not all subrepos will support addremove. We could just abort here, but it looks like addremove has always silently ignored bad paths, except for the exit code.
-
- Nov 10, 2014
-
-
Matt Harbison authored
This will make it easier to support subrepository operations.
-
- Dec 11, 2014
-
-
Enrique A. Tobis authored
-
- Dec 03, 2014
-
-
Martin von Zweigbergk authored
We would eventually like to move the resolution of modify/delete and delete/modify conflicts to the resolve phase. However, we don't want to move the checks for identical content that were added in 902554884335 (merge: before cd/dc prompt, check that changed side really changed, 2014-12-01). Let's instead move these out to a new _resolvetrivial() function that processes the actions from manifestmerge() and replaces any false cd/dc conflicts. The function will also provide a natural place for us to later add code for resolving false 'm' conflicts.
-
- Dec 10, 2014
-
-
Martin von Zweigbergk authored
Instead of iterating over 'g' action, first find the set of all files that are largefiles in p1. Then iterate over these files. This prepares for considering actions other than 'g'.
-
Martin von Zweigbergk authored
In overridecalculateupdates(), we currently only deal with conflicts that result in a 'g' action for either the largefile or a standin. We will soon want to deal cases with 'cd' and 'dc' actions here. It will be easier to reason about such cases if we rewrite it using a dict from filename to action. A side-effect of this change is that the output can only have one action per file (which should be a good change). Before this change, when one of the tests in test-issue3084 received this input (the 'a' in the input was a result of 'cd' conflict resolved in favor of the modified file): 'g': [('.hglf/f', ('',), 'remote created')], 'a': [('f', None, 'prompt keep')], and the user chose to keep the local largefile, it produced this output: 'g': [('.hglf/f', ('',), 'remote created')], 'r': [('f', None, 'replaced by standin')], 'a': [('f', None, 'prompt keep')], Although 'a' actions are processed after 'r' actions by recordupdates(), it still worked because 'a' actions have no effect on merges (only on updates). After this change, the output is: 'g': [('.hglf/f', ('',), 'remote created')], 'r': [('f', None, 'replaced by standin')], Similarly, there are several tests in test-largefiles-update that get inputs like: 'a': [('.hglf/large2', None, 'prompt keep')], 'g': [('large2', ('',), 'remote created')], and when the user chooses to keep the local largefile, they produce this output: 'a': [('.hglf/large2', None, 'prompt keep'), ('.hglf/large2', None, 'keep standin')], 'lfmr': [('large2', None, 'forget non-standin largefile')], In this case, it was not a merge but an update, so the 'a' action does have an effect. However, since dirstate.add() is idempotent, it still has no obserable effect. After this change, the output is: 'a': [('.hglf/large2', None, 'keep standin')], 'lfmr': [('large2', None, 'forget non-standin largefile')],
-
- Dec 09, 2014
-
-
Martin von Zweigbergk authored
The items we put in 'newglist' are always the same as what we found in actions['g'], so let's just put the same item into the list instead of creating a new one.
-
- Dec 08, 2014
-
-
Martin von Zweigbergk authored
The action lists returned from calculateupdates() (in merge.py) are not required to be sorted. In fact, since they result from iteration over the unordered manifest, they are unlikely to be sorted. Moreover, some of the lists are appended to after they are returned from manifestmerge(). The lists are instead sorted in applyupdates(). Therefore, let's not sort the lists generated in largefiles' overridecalculateupdates().
-
- Dec 10, 2014
-
-
Martin von Zweigbergk authored
See earlier patch for motivation.
-
- Dec 09, 2014
-
-
Martin von Zweigbergk authored
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.
-
- Dec 06, 2014
-
-
Martin von Zweigbergk authored
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.
-
- Dec 10, 2014
-
-
Mathias De Maré authored
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é authored
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é authored
This allows checking the git version in other methods, instead of only being able to check if the version is ok or not.
-
- Oct 11, 2012
-
-
kiilerix authored
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.
-
- Dec 10, 2014
-
-
Mads Kiilerich authored
-
Mads Kiilerich authored
Similar to graft: note: rebase of 6:eea13746799a created no changes to commit
-
- Dec 09, 2014
-
-
Mads Kiilerich authored
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.
-
- Dec 07, 2014
-
-
Mads Kiilerich authored
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).
-
- Dec 09, 2014
-
-
Mads Kiilerich authored
Prepare for including hashes in output ... and less globbing make the tests easier to update.
-
durin42 authored
It only needs strip, no reason to load all of mq.
-
- Dec 04, 2014
-
-
Pierre-Yves David authored
It has no known users. If someones needs similar functionality, a new 'addabort' method similar to 'addfinalize' should be added.
-
Pierre-Yves David authored
It is superseded by the 'addfinalize' function and all its user have been migrated.
-
- Dec 05, 2014
-
-
Pierre-Yves David authored
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.
-
- Dec 04, 2014
-
-
Pierre-Yves David authored
Now that we have a shiny generic mechanism, we can use it.
-
- Dec 09, 2014
-
-
Matt Mackall authored
-
Matt Mackall authored
This is either already redundant in the output or too verbose in quiet mode.
-