similar tools is that it
doesn't use a local mercurial clone under the hood (unlike all the
existing other such tools), and is close to an order of magnitude faster
to clone a repository like http://hg.mozilla.org/mozilla-central than
the git-remote-hg tool that used to be shipped in contrib/.
I won't
, bookmarks, phases, obsolescence markers), but it
currently transposes a complete mercurial dag to git and maintains
metadata about the original mercurial data.
Code on https://github.com/glandium/git-remote-hg
It doesn't support push, but support for that should come in the coming
weeks.
More background
Mike Hommey wrote:
I'm currently evaluating what the final tool would look like. I'm *very*
tempted to implement it in C, based on core git code, because there are
many things that this helper does that would be so much easier to do
with direct access to git's guts. And that wouldn't require
that it doesn't handle
(like
named branches, bookmarks, phases, obsolescence markers), but it
currently transposes a complete mercurial dag to git and maintains
metadata about the original mercurial data.
Code on https://github.com/glandium/git-remote-hg
It doesn't support push, but support for that should
On Fri, Dec 05, 2014 at 02:13:19PM -0800, Jonathan Nieder wrote:
Mike Hommey wrote:
I'm currently evaluating what the final tool would look like. I'm *very*
tempted to implement it in C, based on core git code, because there are
many things that this helper does that would be so much
),
then picking one to symlink as git-remote-hg in your $PATH should be
enough.
If they don't have that level of interoperability, then there's an
argument to be made that the URLs shouldn't be the same.
Unfortunately url.*.insteadof rules are resolved at fetch time instead
of being resolved once
On Fri, Dec 05, 2014 at 05:59:30PM -0500, Jeff King wrote:
On Fri, Dec 05, 2014 at 02:13:19PM -0800, Jonathan Nieder wrote:
Mike Hommey wrote:
I'm currently evaluating what the final tool would look like. I'm *very*
tempted to implement it in C, based on core git code, because there
between fetching using each one into the same on-disk git repository),
then picking one to symlink as git-remote-hg in your $PATH should be
enough.
If they don't have that level of interoperability, then there's an
argument to be made that the URLs shouldn't be the same.
I don't think
?
:)
If the helpers are roughly interchangeable (that is, if you can switch
between fetching using each one into the same on-disk git repository),
then picking one to symlink as git-remote-hg in your $PATH should be
enough.
That may be enough. For the most part you do not need to agree with
other members
: The remote helper of Git 1.9.3 is not compatible with hg 3.0
You can eiher downgrade hg, or rebuild Git and cherry-pick this commit:
No need to rebuild Git.
You can also use the latest version:
https://github.com/felipec/git-remote-hg
Thanks Felipe and Torsten, just using the HEAD version of git
:
https://github.com/felipec/git-remote-hg
Thanks Felipe and Torsten, just using the HEAD version of git-remote-hg
solved the problem.
Best regards,
Charles--
I did some testing with Git 2.0-rc3 + 58aee0864adeeb5363f.
The remote-helper tests for hg-git worked OK
with both hg version 2.9
felipe.contre...@gmail.com
Date: Sat May 3 21:16:54 2014 -0500
remote-hg: add support for hg v3.0
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote
-hg and
git-remote-hg are no longer maintained in git.git.
If you hadn't made such a move, you would have your answer, the fix
would be properly explained, the regression fixed, and all your users
would be happy that git-remote-hg and git-remote-bzr get distributed by
default.
--
Felipe Contreras
On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
I did some testing with Git 2.0-rc3 + 58aee0864adeeb5363f.
The remote-helper tests for hg-git worked OK
with both hg version 2.9 and 3.0 under both Mac OS and Linux.
Should we
://github.com/felipec/git-remote-hg.
Cheers.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
/git-remote-hg.
Thanks,
--
William Giokas | KaiSforza | http://kaictl.net/
GnuPG Key: 0x73CD09CF
Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
pgp_mLEPyhosF.pgp
Description: PGP signature
William Giokas wrote:
On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
William Giokas wrote:
On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
Why do we import changegroup unconditionally, even though it
is only used in the new codepath meant
On Tue, May 13, 2014 at 03:24:51PM -0500, Felipe Contreras wrote:
William Giokas wrote:
On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
As you say, it's perfectly OK.
But wrong. Yes, it works, but it's not how it should be done when we
have a code review such as
William Giokas wrote:
On Tue, May 13, 2014 at 03:24:51PM -0500, Felipe Contreras wrote:
William Giokas wrote:
On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
As you say, it's perfectly OK.
But wrong. Yes, it works, but it's not how it should be done when we
everything be this horrible disaster, you redefine
words (regression) to be whatever you need/want them to be to be
git-remote-hg and git-remote-bzr will likely break in Git v2.0 in certain
situations where they wouldn't in v1.9, or v1.8. Call it whatever you
want. I call that a regression
these questions?
1) What is missing from git-remote-hg/bzr in order for them to be
considered to be merged to the core?
2) If a different maintainer steps up, would you consider reconsider
merging them to the core?
3) Is there any chance that in the future you would consider them after
for and against
moving git-remote-hg out of contrib. Those arguments were discussed at
length and I think their weight is on the side of not moving it. But
there are two other (in my opinion, stronger) reasons for keeping
git-remote-hg out of the core:
1. That subproject has not been maintained
2014-05-12 10:12 GMT+02:00 Felipe Contreras felipe.contre...@gmail.com:
Felipe Contreras wrote:
Linus Torvalds wrote:
Felipe, stop this stupid blaming of everybody but yourself.
Show me evidence that this decision was my fault. Junio certainly hasn't
said so. You just have no idea what we
, but suddenly Junio changed his mind.
I agree with Junio. There are good technical arguments for and against
moving git-remote-hg out of contrib. Those arguments were discussed at
length and I think their weight is on the side of not moving it. But
there are two other (in my opinion, stronger
. There are good technical arguments for and against
moving git-remote-hg out of contrib.
Saying you agree with Junio is content-free. You have to say *why* you
agree.
You mention there are good technical arguments against the graduation of
the tools. Surely if you have analyzed those arguments enough
Michael Haggerty mhag...@alum.mit.edu writes:
This email is written in sorrow, not in anger. Felipe, you seem to
have so much potential. If you would put as much effort in conducting
social interactions as you do in coding, [...]
I think that's where you are mistaken. We are not talking
changed his mind.
I agree with Junio. There are good technical arguments for and against
moving git-remote-hg out of contrib.
Saying you agree with Junio is content-free. You have to say *why* you
agree.
Actually, I don't have to, not even if you tell me to. And anyway, I
think the small
Stefan Beller wrote:
2014-05-12 10:12 GMT+02:00 Felipe Contreras felipe.contre...@gmail.com:
Felipe Contreras wrote:
Linus Torvalds wrote:
Felipe, stop this stupid blaming of everybody but yourself.
Show me evidence that this decision was my fault. Junio certainly hasn't
said so. You
under way, but suddenly Junio changed his mind.
I agree with Junio. There are good technical arguments for and against
moving git-remote-hg out of contrib.
Saying you agree with Junio is content-free. You have to say *why* you
agree.
Actually, I don't have to,
Then there's no point
Paolo Ciarrocchi wrote:
On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty
mhag...@alum.mit.eduwrote:
Felipe, you seem to have so much potential. If you would put as
much effort in conducting social interactions as you do in coding,
the whole balance would change entirely, and any
from contrib to the core[1]. This move is already
under way, but suddenly Junio changed his mind.
I agree with Junio. There are good technical arguments for and against
moving git-remote-hg out of contrib.
Saying you agree with Junio is content-free. You have to say *why* you
agree
On 05/12/2014 02:29 PM, Felipe Contreras wrote:
Michael Haggerty wrote:
[...]
2. Moving git-remote-hg into the core would require you to continue your
presence on the Git mailing list.
That is another red herring. Moving them back to the contrib/ area which
is what Junio proposed would
On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Paolo Ciarrocchi wrote:
On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty
mhag...@alum.mit.eduwrote:
While I agree with you the this project is managed in a bit conservative
way
Only a bit? I don't
:
searching for changes
no changes found
searching for changes
Traceback (most recent call last):
File /usr/local/bin/git-remote-hg, line 1254, in module
sys.exit(main(sys.argv))
File /usr/local/bin/git-remote-hg, line 1238, in main
do_export(parser)
File /usr/local/bin/git-remote-hg, line
2014-05-12 15:45 GMT+02:00 Paolo Ciarrocchi paolo.ciarroc...@gmail.com:
No, sorry but I'm NOT interested in lying to git community.
It's not lying. See the Helped-By: lines in git.git commits.
Often the help was formulating a correct and easy-to-understand
commit message.
--
To unsubscribe
Paolo Ciarrocchi wrote:
On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Paolo Ciarrocchi wrote:
On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty
mhag...@alum.mit.eduwrote:
While I agree with you the this project is managed in a bit conservative
Michael Haggerty wrote:
On 05/12/2014 02:29 PM, Felipe Contreras wrote:
Michael Haggerty wrote:
[...]
2. Moving git-remote-hg into the core would require you to continue your
presence on the Git mailing list.
That is another red herring. Moving them back to the contrib/ area which
I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew.
It used to work before, on this same repository, since then git and hg were
both upgraded.
In short: The remote helper of Git 1.9.3 is not compatible with hg 3.0
You can eiher downgrade hg, or rebuild Git and
hg, or rebuild Git and cherry-pick this commit:
No need to rebuild Git.
You can also use the latest version:
https://github.com/felipec/git-remote-hg
--
Felipe Contreras--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
he will do that in this thread, but
I'll jump ahead and assume it's this one by John Keeping[2]:
I do not want to end up in a situation where an update to Git is
blocked by a distribution because git-remote-hg is not updated to
support newer versions of Mercurial sufficiently quickly
Hi,
git-remote-hg is a bidirectional bridge between Git and Mercurial. It is
production-ready, has been widely tested, and was previously part of
git.git.
Junio C Hamano has retracted from his previous statements where he
wanted these tools to become part of the Git core and distributed
-hg.txt b/Documentation/git-remote-hg.txt
new file mode 100644
index 000..0cceb76
--- /dev/null
+++ b/Documentation/git-remote-hg.txt
@@ -0,0 +1,121 @@
+git-remote-hg(1)
+
+
+NAME
+
+git-remote-hg - bidirectional bridge between Git and Mercurial
+
+
+SYNOPSIS
From: Daniel Liew delcyp...@gmail.com
Use the hgrc configuration file in the internal mercurial repository in
addition to the other system wide hgrc files. This is done by using the
'ui' object from the 'repository' object which will have loaded the
repository hgrc file if it exists.
Delcypher wrote:
What is the problem you are trying to solve?
The problem I was trying to solve is I wanted my authentication
details to be in a hgrc local to the repository.
The problem is git-remote-hg will parse
``.git/hg/origin/clone/.hg/hgrc`` but will ignore any settings
What version of Mercurial are you using?
$ hg --version
Mercurial Distributed SCM (version 2.9.2)
(see http://mercurial.selenic.com for more information)
Copyright (C) 2005-2014 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even
Delcypher wrote:
What version of Mercurial are you using?
$ hg --version
Mercurial Distributed SCM (version 2.9.2)
Same as me. And which version of git-remote-hg are you using?
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message
Same as me. And which version of git-remote-hg are you using?
I'm using the version that ships with git 1.9.2
I've taken a look and it seems I made a mistake, sorry. It seems that
[ui]
quiet = True
is being respected when placed in ``.git/hg/origin/clone/.hg/hgrc``
with the un patched
Delcypher wrote:
Same as me. And which version of git-remote-hg are you using?
I'm using the version that ships with git 1.9.2
I've taken a look and it seems I made a mistake, sorry. It seems that
[ui]
quiet = True
is being respected when placed in ``.git/hg/origin/clone/.hg/hgrc
I see now, I've taken the patch with repo.ui and applied on my repo:
https://github.com/felipec/git/commit/ee17fe1cf80d5196be382ebbbcb1a24c05e61658
Thanks.
It might be helpful to catch the exception raised if https
authentication details are missing so that a more user friendly error
message
What is the problem you are trying to solve?
The problem I was trying to solve is I wanted my authentication
details to be in a hgrc local to the repository.
The problem is git-remote-hg will parse
``.git/hg/origin/clone/.hg/hgrc`` but will ignore any settings in it
(this seems a little silly
Christophe wrote:
I am using git-remote-hg to access to projects on bitbucket. I can clone the
master branch fine and push to it. I also see hg branches as
remotes/origin/branches/«branch». However, if I create a local branch
branches/x and want to push it to remotes/origin/branches/x
ping.
On 21 February 2014 15:17, Daniel Liew delcyp...@gmail.com wrote:
git-remote-hg : Enable use of, $GIT_DIR/hg/origin/clone/.hg/hgrc
Use the hgrc configuration file in the internal mercurial repository in
addition to the other system wide hgrc files. This is done by using the
'ui' object
git-remote-hg : Enable use of, $GIT_DIR/hg/origin/clone/.hg/hgrc
Use the hgrc configuration file in the internal mercurial repository in
addition to the other system wide hgrc files. This is done by using the
'ui' object from the 'repository' object which will have loaded the
repository hgrc file
Hi,
I am using git-remote-hg to access to projects on bitbucket. I can
clone the master branch fine and push to it. I also see hg branches
as remotes/origin/branches/«branch». However, if I create a local
branch branches/x and want to push it to remotes/origin/branches/x,
it gets pushed
to this problem.
Signed-off-by: Brian Gernhardt br...@gernhardtsoftware.com
---
contrib/remote-helpers/git-remote-hg | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 0194c67..7fa6cd7 100755
--- a/contrib/remote
PM, Amit Bakshi ambak...@gmail.com wrote:
git clone hangs on windows (msysgit/cygwin), and
file.write would return errno 22 inside of mercurial's
windows.winstdout wrapper class. This patch sets
stdout's mode to binary, fixing both issues.
---
contrib/remote-helpers/git-remote-hg | 21
-helpers/git-remote-hg | 21 +
1 file changed, 21 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 328c2dc..95f4c1f 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
[+CC: Felipe, the author and maintainer of the script]
Samuel Chase wrote:
I just used git-remote-hg to convert a small hg repository.
It worked perfectly.
We'll be happy to address any deficiencies/ warts you find in everyday usage.
Thanks.
--
To unsubscribe from this list: send the line
sets
stdout's mode to binary, fixing both issues.
---
contrib/remote-helpers/git-remote-hg | 21 +
1 file changed, 21 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 328c2dc..95f4c1f 100755
--- a/contrib
Hi,
In a recent e-mail[1] it was suggested that gitifyhg and git-remote-hg had many
differences, and that some users might be best served by using gitifyhg. While
that e-mail was answered properly, I would like to point out what are the
actual differences that affect users, not the ones
60 matches
Mail list logo
