- Sep 27, 2012
-
-
Pierre-Yves David authored
When histedit "continue", there is several complicated logic to apply in order to detect intermediate changeset and concluded pending operation. This changeset extract this logic in a dedicated function to lighten the main one. No alteration to the logic is done.
-
- Sep 26, 2012
-
-
Pierre-Yves David authored
I expected `tip` to be repo's tip when it was the rewritten set tip. I rename the variable to the less ambiguous `topmost`.
-
Pierre-Yves David authored
Create a function dedicated to stripping a group of node. All existing duplicated code is replaced by call to this function. This new function take care of stripping known and relevant node only.
-
Pierre-Yves David authored
This lighten the main function and will help to see future changes to this bookmark logic.
-
Pierre-Yves David authored
- `node.hex(n)[:12]` is the same as `node.short(n)` - `ctx.hex()[:12]` is the same as `str(ctx)`
-
- Sep 27, 2012
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Jul 31, 2012
-
-
Matt Harbison authored
Previously, even if a file was added with --large, 'hg addremove' or 'hg ci -A' would add all files (including the previously added large files) as normal files. Only after a commit where a file was added with --large would subsequent adds or 'ci -A' take into account the minsize or the pattern configuration. This change more closely follows the help for largefiles, which mentions that 'add --large' is required to enable the configuration, but doesn't mention the previously required commit. Also, if 'hg add --large' was performed and then 'hg forget <file>' (both before a largefile enabling commit), the forget command would error out saying '.hglf/<file> not tracked'. This is also fixed. This reports that a repo is largefiles enabled as soon as a file is added with --large, which enables 'add', 'addremove' and 'ci -A' to honor the config settings before the first commit. Note that prior to the next commit, if all largefiles are forgotten, the repository goes back to reporting the repo as not largefiles enabled. It makes no sense to handle this by adding a --large option to 'addremove', because then it would also be needed for 'commit', but only when '-A' is specified. While this gets around the awkwardness of having to add a largefile, then commit it, and then addremove the other files when importing an existing codebase (and preserving that extra commit in permanent history), it does still require finding and manually adding one of the files as --large. Therefore it is probably desirable to have a --large option for init as well.
-
Matt Harbison authored
Previous to this, 'commit -A' would add as normal files, files that were already committed as largefiles, resulting in files being listed twice by 'status -A'. It also missed when (only) a largefile was deleted, even though status reported it as '!'. This also has the side effect of properly reporting the state of the affected largefiles in the post commit hook after a remove that also affected a normal file (the largefiles used to be 'R', now are properly absent). Since scmutil.addremove() is called both by the ui command (after some trivial argument validation) and during the commit process when -A is specified, it seems like a more appropriate method to wrap than the addremove command. Currently, a repo is only enabled to use largefiles after an add that explicitly identifies some file as large, and a subsequent commit. Therefore, this patch only changes behavior after such a largefile enabling commit. Note that in the test, if the final commit had a '-v', 'removing large8' would be printed twice. Both of these originate in removelargefiles(). The first print is in verbose mode after traversing remove + forget, the second is because the '_isaddremove' attr is set and 'after' is not.
-
- Sep 25, 2012
-
-
Alexander Sauta authored
-
Alexander Sauta authored
-
- Sep 14, 2012
-
-
Nikolaj Sjujskij authored
-
- Aug 30, 2012
-
-
Katsunori FUJIWARA authored
-
Katsunori FUJIWARA authored
For backwards compatibility, "opener" fields are still left as aliases for "vfs" ones.
-
Katsunori FUJIWARA authored
-
Katsunori FUJIWARA authored
-
Katsunori FUJIWARA authored
This patch also changes initialization order of "*opener" and "*vfs" fields: first, "*vfs" fields are initialized , and then, "*opener" ones are initialized.
-
Katsunori FUJIWARA authored
For backwards compatibility, aliases for the old names are added, except for "abstractopener", "statichttpopener" and "_fncacheopener", because these are not used in Mercurial core implementation after this patch. "_fncacheopener" was only referred in "fncachestore" constructor, so this patch also renames from "_fncacheopener" to "_fncachevfs" there.
-
- Aug 13, 2012
-
-
Katsunori FUJIWARA authored
This patch adds "doc/check-seclevel.py" which checks below in help documents: - whether unknown or unavailable section marks are used or not - whether appropriate section mark is used at sub-sectioning It should be invoked in "doc" directory. It checks all help documents of Mercurial (topics, commands, extensions), if no file is specified by --file option. With --file option, it checks contents of the specified file as help document, for self testing purpose: -t/-c/-e/-C are used to specify what kind of help document contents of the specified file is. This checking is related to changeset 979b107eaea2.
-
- Sep 21, 2012
-
-
Pierre-Yves David authored
The old and fragile patching logic is replaced by smart merges (as rebase and graft do). This should prevents some conflicts and smoother human resolution. For this purpose the "foldchanges" function is renamed to "applychanges" and handle a single revision only.
-
Pierre-Yves David authored
The previous version would commute if using merge algorithm (to be accurate, merge will cleanly prompt the user during the merge). The new version create and initial commit with some content for all involved files en ensure all changes are a content changes of the first lines. This lead to guaranteed conflict when commuted.
-
Pierre-Yves David authored
This is very useful when debugging histedit.
-
Pierre-Yves David authored
Update the folding code to works in memory instead of applying patches on the working directory. This is cleaner, faster and prepare the removal of the whole patching logic. This new collapse function will probably move into core sooner or later. A lot of other rewriting operation may benefit from it.
-
- Sep 20, 2012
-
-
Pierre-Yves David authored
Having it in the middle of action logic is confusing
-
- Sep 21, 2012
-
-
Pierre-Yves David authored
Having this function in the middle of action and patching logic did not make sense
-
- Sep 20, 2012
-
-
Pierre-Yves David authored
-
Pierre-Yves David authored
-
- Sep 24, 2012
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
- Sep 22, 2012
-
-
Matt Mackall authored
This allows: {join(files % "{files}", ", ") }\n to produce a properly comma-separated list
-
Matt Mackall authored
As a side-effect, this makes the output of runmap non-flattened
-
- Sep 21, 2012
-
-
Matt Mackall authored
-
David M. Carr authored
This alternate syntax was proposed by Bryan O'Sullivan in a review of 772b3764d3e8. I haven't been able to measure any particular performance difference, but the new syntax is more concise and easier to read.
-
- Sep 19, 2012
-
-
Bryan O'Sullivan authored
-
- Sep 18, 2012
-
-
Katsunori FUJIWARA authored
Before this patch, zip archives created by "hg archive" are extracted with unexpected timestamp, if TZ is not configured as GMT. This patch adds "extended-timestamp" extra block to zip archives, and unzip will extract such archives with timestamp specified in added extra block, even though TZ is not configured as GMT. Please see documents below for detail about specification of zip file format and "extended-timestamp" extra block: http://www.pkware.com/documents/casestudies/APPNOTE.TXT http://www.opensource.apple.com/source/zip/zip-6/unzip/unzip/proginfo/extra.fld Original implementation of this patch was suggested by "Jun Omae <jun66j5@gmail.com>".
-
Katsunori FUJIWARA authored
This patch uses "old.descendant(new)" expression instead of "new in old.descendants()" for efficiency.
-