- Dec 14, 2013
- Dec 13, 2013
- Dec 03, 2013
-
-
Jordi Gutiérrez Hermoso authored
-
- Nov 27, 2013
-
-
Ben Kehoe authored
-
- Oct 05, 2013
-
-
Augie Fackler authored
README: add URLs of homepage, primary hg repo, and git mirror repo
-
- Jun 26, 2012
-
-
Brian Warner authored
-
- Oct 05, 2013
-
-
durin42 authored
This was crafted mostly via a bunch of aimless flailing in the code. I'm pretty well convinced at this point that the incoming support needs to be rewritten slightly to behave properly in the new world order (specifically, the overlayrepo class probably should be subclassing localrepo, or else more directly reimplementing things instead of trying to forward methods.)
-
- Sep 17, 2013
-
-
durin42 authored
I've been waiting for dulwich upstream to fix this *and* for a test from domruf that's acceptable. Having gotten neither over a period of /months/, and having hit the bug myself, I'm moving on and accepting a patch without tests. This will likely break again, but hopefully before we'd break it dulwich will be fixed.
-
durin42 authored
-
durin42 authored
-
- Dec 11, 2012
-
- Sep 13, 2013
-
-
Alex Regueiro authored
-
Alex Regueiro authored
-
- Aug 28, 2013
- Aug 12, 2013
-
-
nsuke authored
-
- Jul 10, 2013
-
-
Risto Kankkunen authored
-
- Jul 01, 2013
-
-
André Felipe Dias authored
Test case based on the one proposed by David Carr at https://bitbucket.org/durin42/hg-git/issue/54/with-option-branch_bookmark_suffix-set
-
- Apr 14, 2013
-
-
Gregory Szorc authored
Previously, we emitted every Git tree when updating between Mercurial changesets. With this patch, we now only emit Git trees that changed. A side-effect of the implementation is that we now only update in-memory Git trees objects that changed. Before, we always touched Git trees, invalidating them in the process and causing Dulwich to recalculate their SHA-1. Profiling revealed this to be expensive and removing the extra calculation shows a nice performance win. Another optimization is to not sort the order that changed paths are processed in. Previously, we sorted by length, longest to shortest. Profiling revealed that the sorts took a non-trivial amount of time. While sorted execution resulted in likely idempotent behavior, it shouldn't be strictly required. On the author's machine, conversion of the Mercurial repository itself decreased from ~493s to ~333s. Even more impressive is conversion of Firefox's main repository (which is considerably larger). Converting the first 200 revisions of that repository decreased from ~152s to ~42s.
-
- Apr 03, 2013
-
-
durin42 authored
-
- Mar 20, 2013
-
-
Gregory Szorc authored
This replaces the brute force Mercurial to Git export with one that is incremental. It results in a decent performance win and paves the road for parallel export via using multiple incremental exporters.
-
- Mar 24, 2013
-
-
durin42 authored
-
- Feb 07, 2013
-
-
Hal Wine authored
A recent real world occurrence - user hand edited the timezone field in an hg export to provide a unique value (from prior export). Hg imported the export okay, but dulwich threw an exception. This test shows the fault.
-
- Feb 05, 2013
-
-
Hal Wine authored
If dulwich is presented with a "sub minute" timezone offset, it throws an exception (see tests/test-timezone.t). This patch rounds the timezone down to the next minute before passing the value to dulwich.
-
- Jan 06, 2013
-
-
David M. Carr authored
As pointed out by l33t, Hg-Git's output for push doesn't currently do a very good job of telling the user what happened. My previous changes in this area had moved some of the output from status to note, making it only show if --verbose was specified. However, I hadn't realized at the time that the reference information (though overly verbose) was providing a valueable purpose that otherwise wasn't met; telling the user that a remote reference had changed. This changeset makes it so that: * default output will include simple messages like "adding reference refs/heads/feature" and "updating reference refs/heads/master" (omitting any mention of unchanged references) * verbose output will include more detailed messages like "adding reference default::refs/heads/feature => GIT:aba43c" and "updating reference default::refs/heads/master => GIT:aba43c" (omitting any mention of unchanged references) * debug output will include the detailed output like in verbose, but addtionally will include messages like "unchanged reference default::refs/heads/other => GIT:aba43c" https://bitbucket.org/durin42/hg-git/issue/64/push-confirmation
-
David M. Carr authored
l33t pointed out that currently, Hg-Git doesn't provide any confirmation that a push was successful other than the exit code. Normal Mercurial provides a couple other messages followed by "added X changesets with Y changes to Z files". After this change, Hg-Git will provide much more similar output. It's not identical, as the underlying model is substantially different, but the concept is the same. The main message is "added X commits with Y trees and Z blobs". This change doesn't affect the output of what references/branches were touched. That will be addressed in a subsequent commit. Dulwich doesn't provide an easy hook to get the information needed for this output. Instead of passing generate_pack_contents as the pack generator function to send_pack, I pass a custom function that determines the "missing" objects, stores the counts, and then calls generate_pack_contents (which then will determine the "missing" objects again. The new expected output: searching for changes # unless quiet true <N> commits found # if verbose true list of commits: # if debugflag true and at least one commit found <each hash> # if debugflag true and at least one commit found adding objects # if at least one commit found unless quiet true added <N> commits with <N> trees and <N> blobs # if at least one object unless # quiet true https://bitbucket.org/durin42/hg-git/issue/64/push-confirmation
-
- Nov 24, 2012
-
-
durin42 authored
-
- Nov 22, 2012
-
-
David M. Carr authored
Prior to this fix, tests against the latest hg codebase would fail with: creating bookmarks failed, do you have bookmarks enabled?
-
- Nov 11, 2012
- Nov 04, 2012
-
-
David M. Carr authored
In c4849b2dab87, the "commit" function was extracted into a testutil for re-use. However, test-encoding.t was skipped over in that changeset, as I was seeing unexplained test failures. Since those test failures have now been explained (and fixed), this changeset performs the same extraction on test-encoding.t as was done on all the other tests. The version of fn_git_commit that was used in testutil redirected all output (including errors) to /dev/null, which didn't match the expectations of this test. The test utility functions for commit/tag now no longer throw away error output, instead leaving it to individual tests to decide if error output should be ignored.
-
David M. Carr authored
It looks like Git 1.8.0 started silently converting latin1 commit messages to utf-8. That changed the result of this test. This changeset alters the test to make it accept both the pre-1.8.0 and post-1.8.0 behaviors. https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.0.txt
-