- 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.
-
- Jan 30, 2015
- Jan 27, 2015
-
-
Siddharth Agarwal authored
Looks like we use many more dict APIs in overlaymanifest.
-
Siddharth Agarwal authored
I have no idea why this used to return a changectx -- changelog.read() in core has always returned a tuple.
-
Siddharth Agarwal authored
This allows test-incoming.t to progress further.
-
- Dec 30, 2014
-
-
Siddharth Agarwal authored
See comment inline for explanation. Also add tests for this (the bug was masked with rename detection disabled -- it only appeared with rename detection enabled).
-
Siddharth Agarwal authored
There weren't any bugs here, but this is good to test.
-
Siddharth Agarwal authored
This adds some test coverage for cases that are not buggy. There is a bug lurking here, and an upcoming patch will extend these tests to cover those cases too.
-
- Nov 24, 2014
-
-
durin42 authored
A user recently got confused and managed to track and export a .git directory, which confuses git and causes it to emit very odd errors. For example, cloning one such repository (which has a symlink for .git) produces this output from git: Cloning into 'git'... done. error: Updating '.git' would lose untracked files in it and another (which has a .git directory checked in) produces this: Cloning into 'git'... done. error: Invalid path '.git/hooks/post-update' If it ended there, that'd be fine, but this led to a line of investigation that ended with CVE-2014-9390, so now git will block checking these revisions out, so we should try to prevent foot-shooting on our end. Since some servers (notably github) are blocking trees that contain these entries, default to refusing to export any path component that looks like it folds to .git. Since some histories probably contain this already, we offer an escape hatch via the config option git.blockdotgit that allows users to resume foot-shooting behavior.
-
- Dec 29, 2014
-
-
Siddharth Agarwal authored
-
- Dec 10, 2014
-
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
Without the try/except, hg-git crashes with Mercurial 3.2. Oops.
-
- Dec 05, 2014
-
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
In a previous commit we started storing metadata in Git whenever commits originated in Mercurial, so this is no longer a heuristic.
-
- Dec 02, 2014
-
-
Siddharth Agarwal authored
See inline comments for why the additional metadata needs to be stored. This literally breaks all the hashes because of the additional metadata. The changing of hashes is unfortunate but necessary to preserve bidirectionality. While this could be broken up into multiple commits, there was no way to do that while preserving bidirectionality. Following the principle that every intermediate commit must result in a correct state, I decided to combine the commits.
-
Siddharth Agarwal authored
We use Dulwich's rename detector to detect any renames over the specified similarity threshold. This isn't fully bidirectional yet -- when the commit is exported to Git the hashes will no longer be the same. That's why that isn't tested here. In upcoming patches we'll make sure it's bidirectional and will add the corresponding tests.
-
- Dec 06, 2014
-
-
paul wheeler authored
-
Siddharth Agarwal authored
Mercurial rev 52db731b964d introduced a transaction manager upstream. This means that the closetransaction and releasetransaction methods on the pull operation have gone away.
-
- Dec 02, 2014
-
-
Siddharth Agarwal authored
We currently return an empty dictionary -- we'll fill it in upcoming patches.
-
Siddharth Agarwal authored
This will be used to detect renames in upcoming patches.
-
Siddharth Agarwal authored
object_store.tree_changes doesn't allow us to specify a rename detector, but diff_tree's tree_changes does.
-
Siddharth Agarwal authored
get_files_changed doesn't do anything with this yet, but it will in upcoming patches.
-
Siddharth Agarwal authored
In upcoming patches we'll add other sources of renames.
-
Siddharth Agarwal authored
This is currently a heuristic -- it'll be made more reliable in upcoming patches.
-
- Dec 05, 2014
-
-
Siddharth Agarwal authored
Git 1.8.0 was released in late 2012. Given that we only support versions of Mercurial released in 2014, it doesn't make sense to support versions of Git this old.
-