- May 08, 2015
-
-
Siddharth Agarwal authored
-
- May 03, 2015
-
-
Siddharth Agarwal authored
-
- Apr 29, 2015
-
-
durin42 authored
-
- Apr 22, 2015
-
-
Sean Farley authored
-
Sean Farley authored
This method had a syntax error that would have caused a crash.
-
Sean Farley authored
-
Sean Farley authored
-
Sean Farley authored
-
Sean Farley authored
-
Sean Farley authored
-
Sean Farley authored
-
Sean Farley authored
-
- Apr 17, 2015
-
-
Sean Farley authored
Also cleans up some unused imports.
-
- Apr 16, 2015
-
-
Sean Farley authored
-
- Apr 15, 2015
-
-
Sean Farley authored
-
Sean Farley authored
All errors found with flake8.
-
Sean Farley authored
-
- Apr 10, 2015
-
-
Siddharth Agarwal authored
There really is no point to this -- the sorting is expensive to compute and the structure is never actually used. For a mapfile with 1.5 million entries, this speeds up save_map from 3.6 seconds to 0.87. This is probably the limit of the speedups we can get with pure-Python code. Any further speedups will have to be made by rewriting these bits in C.
-
- Apr 13, 2015
-
-
Siddharth Agarwal authored
There are a couple of places that use StringIO for the added features it has over cStringIO, so we can't replace all its uses wholesale.
-
- Apr 10, 2015
-
-
Siddharth Agarwal authored
For a mapfile with 1.5 million entries, this speeds up save_map from 3.5 seconds to 3.1.
-
Siddharth Agarwal authored
Sorting a list of tuples is much more expensive than sorting a list of strings. For a mapfile with 1.5 million entries, this speeds up save_map from 6 seconds to 3.5.
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
For a mapfile with 1.5 million entries, this speeds up load_map from 2.3 seconds to 1.8.
-
Siddharth Agarwal authored
For a mapfile with 1.5 million entries, this speeds up perfgitloadmap from 2.5 seconds to 2.3.
-
Siddharth Agarwal authored
In upcoming patches we'll make performance improvements to core routines. This extension will allow us to measure their impact.
-
- Apr 03, 2015
-
-
Siddharth Agarwal authored
In Mercurial, every commit has at least one parent -- root commits have the null revision as their parent. In Git, root commits don't have any parents. This difference needs to be papered over in hg-git for 'hg incoming' to work in Mercurial 3.4+. Note that this doesn't fix all the broken tests in default -- I haven't had time to investigate the others.
-
Siddharth Agarwal authored
Since 2bb13f2b778c in Mercurial, _walkexplicit returns a tuple, so ensure we are up to date and take the normalized path which is the first part of the tuple. Based on a patch by David Soria Parra <davidsp@fb.com>.
-
Siddharth Agarwal authored
-
- Mar 12, 2015
-
-
Siddharth Agarwal authored
The bookmark output has been stable since well before the oldest Mercurial we support, 2.8.
-
- Mar 06, 2015
-
-
Siddharth Agarwal authored
It's the version that ships with the latest Ubuntu LTS as of this writing.
-
- Mar 05, 2015
-
-
Siddharth Agarwal authored
While this has been done since the beginning of time, there's no apparent justification for it. If an imported commit works out to the same hash as an existing one, it simply won't be added to the revlog. The tests all continue to pass. There's already test coverage for reimporting commits in test-pull-after-strip.t. Also, gimport has worked this way all this while.
-
Siddharth Agarwal authored
This seems to be a holdover from the days when we used to fetch the entire pack from the Git server in listkeys. We don't do that any more, so this is also unnecessary.
-
- Feb 27, 2015
-
-
Siddharth Agarwal authored
Consider a Mercurial commit with hash 'h1'. Originally, if the only Mercurial field stored is the branch info (which is stored in the commit message rather than as an extra field), we'd store the rename source explicitly as a Git extra field -- let's call the original exported hash 'g1'. In Git, some operations throw all extra fields away. (One such example is a rebase.) If such an operation happens, we'll be left with a frankencommit with the branch info but without the rename source. Let's call this hash 'g2'. For a setup where Git is the source of truth, let's say that this 'g2' frankencommit is what gets pushed to the server. When 'g2' is subsequently imported into Mercurial, we'd look at the fact that it contains a Mercurial field in the commit message and believe that it was a legacy commit from the olden days when all info was stored in the commit message. In that case, in an attempt to preserve the hash, we wouldn't store any extra rename source info, resulting in 'h1'. Then, when the commit is re-exported to Git, we'd add the rename source again and produce 'g1' -- and thus break bidirectionality. Prevent this situation by not storing the rename source if we're adding branch info to the commit message. Then for 'h1' we export as 'g2' directly and never produce 'g1'. What happens if we not only need to store branch info but also other extra info, like renames? For 'h1' we'd produce 'g1', then it'd be rewritten on the Git side to 'g2' throwing away all that extra information. 'g2' being subsequently imported into Mercurial would produce a new hash, say 'h2'. That's fine because the commit did get rewritten in Git. We unfortunately wouldn't perform rename detection thinking that the commit is from Mercurial and had no renames recorded there, but when the commit is re-exported to Git we'd export it to 'g2' again. This at least preserves bidirectionality.
-
Siddharth Agarwal authored
Unlike the file to symlink transition discussed in the previous case, this case works fine.
-
Siddharth Agarwal authored
This edge case that rename detection introduces wasn't handled previously -- the file would be renamed but the symlink wouldn't be added.
-
- Feb 23, 2015
-
-
durin42 authored
-
Jelmer Vernooij authored
-
- Feb 21, 2015
-
-
Paul Chen authored
-
- Feb 16, 2015
-
-
Mathias De Maré authored
Deleting a .gitignore using 'rm' results in 'hg add' or 'hg status' aborting. For example if the top-level .gitignore is removed: > abort: No such file or directory: .gitignore This change avoids that by checking the presence of the .gitignore files.
-