- 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.
-
- Dec 01, 2014
-
-
durin42 authored
-
- Nov 30, 2014
-
-
Siddharth Agarwal authored
These are used just once, so generators are fine for them.
-
Siddharth Agarwal authored
hg-git translates octopus merges into a series of merges, called an octopus explosion. The intermediate octopus explosion commits are not recorded in the mapfile -- only the final commit is. This means that they show up in the export list and have to then be detected and filtered out. Don't initialize the incremental exporter with octopus explosion commits. Previously, if there were octopus merges early in the history, we'd initialize the incremental exporter with the first one's parent, then calculate the diff of that against the first commit we actually cared about exporting. That's slow and wasteful. For a particular real-world repo with one octopus merge 1/3 of the way in history, this is a 10x improvement for 'hg gexport' with one commit to export -- 60 seconds to 6.
-
Siddharth Agarwal authored
This prepares for an upcoming patch. In theory, we could pass the context into export_hg_commit, but there's some encoding shenanigans going on there that I don't want to delve into.
-
- Nov 25, 2014
-
-
Durham Goode authored
0cc283f44655 in upstream Mercurial added a matches function to the manifest. This broke 'hg incoming -p' with hg-git. This patch adds a simple implementation that fixes the problem. This was caught by the tests, and now the tests pass.
-
- Nov 05, 2014
-
-
durin42 authored
-
- Nov 04, 2014
-
-
Siddharth Agarwal authored
Previously we'd crash on annotated tags because they don't have a 'tag_time' property.
-
- Oct 30, 2014
-
-
Siddharth Agarwal authored
-
- Oct 31, 2014
-
-
Siddharth Agarwal authored
-
- Oct 30, 2014
-
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
This is useful if there's no desire to import old Git branches, but new ones should be.
-
- Oct 31, 2014
-
-
Siddharth Agarwal authored
This is quite similar to syntax Git supports. In the future maybe core Mercurial could be extended to support this, but I think this independently makes sense in hg-git.
-
Siddharth Agarwal authored
Again, no direct impact in stock hg-git, but super useful for extensions.
-
Siddharth Agarwal authored
This actually has no direct impact here, but it allows extensions to customize the list of filtered refs and be sure of the order in which they'll be processed.
-
- Oct 29, 2014
-
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
The comment was actually incorrect -- we only used to care about bookmarks. Now we also care about tags.
-
Siddharth Agarwal authored
This also means we get to clean up a lot of the code around here. It isn't really feasible to break this up into several commits because the assumptions in the old calling code are too closely tied to the old local_heads() way of doing things.
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
This is a replacement for local_heads and code duplication around it. Centralizing all this logic also makes it much easier for extensions to define other sorts of refs.
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
There was previously an attempt to handle this but no test coverage.
-
- Oct 28, 2014
-
-
Siddharth Agarwal authored
-
- Oct 29, 2014
-
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
-
Siddharth Agarwal authored
This allows extensions to add other sources of git refs. The returned git ref is currently unused -- the following patch will use it.
-