other 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/
work. Maybe we need a layer of indirection?
> > :)
>
> 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.
Tha
a layer of indirection?
> > :)
>
> 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.
>
> If the
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, bec
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.
Unfortunately url.*.insteadof ru
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 m
at 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 suppo
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 requi
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 come in the coming
wee
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 don
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 s
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 n
it.git, git's maintained out-of-tree (thanks to Junio's
> decisions).
I still see it in git.git, and I will contribute this upstream for as
long as it is in the tree. If you want to use the patch that I sent to
this list, feel free.
> So please post your suggestions and patches to git...@googlegroups.com,
> and use the latest code at https://github.com/felipec/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
t, git's maintained out-of-tree (thanks to Junio's
decisions).
So please post your suggestions and patches to git...@googlegroups.com,
and use the latest code at https://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
On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
> Torsten Bögershausen 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 cons
our stupid decision for which
you still haven't provided a rationale, the git-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
hat commit is the best
solution to the problem.
[References]
*1* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248348
*2*
commit 58aee0864adeeb5363f2a06728596f9c9315811f
Author: Felipe Contreras
Date: Sat May 3 21:16:54 2014 -0500
remote-hg: add support for hg v3.0
d 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-remote-hg
> solved the problem.
>
> Best re
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 cherry-pick this commit:
>
> No need to rebuild Git.
>
> You can also use the latest version:
> https://github.com/felipec/git-remote-h
ible 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
--
Felipe Contreras--
To unsubscribe from this list: send the line "unsubscribe
> 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 cherry-
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
Let me spell it out for you. Michael states "I agree with Junio. There
> are good technical arguments for and against moving git-remote-hg out of
> contrib." Since there are arguments for both sides, the decision boils
> down to a judgment call. Michael states that he condones
Paolo Ciarrocchi wrote:
> On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras
> wrote:
> > Paolo Ciarrocchi wrote:
> > > On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty
> > > wrote:
>
> > > While I agree with you the this project is managed in a bit conservative
> > > way
> >
> > Only a bit? I
2014-05-12 15:45 GMT+02:00 Paolo Ciarrocchi :
>
> 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 from this list: send
n
Password:
searching for changes
no changes found
searching for changes
Traceback (most recent call last):
File "/usr/local/bin/git-remote-hg", line 1254, in
sys.exit(main(sys.argv))
File "/usr/local/bin/git-remote-hg", line 1238, in main
do_export(parser)
File
On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras
wrote:
>
> Paolo Ciarrocchi wrote:
> > On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty
> > wrote:
> >
> > While I agree with you the this project is managed in a bit conservative
> > way
>
> Only a bit? I don't think I've been involed in a mor
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/ ar
f other people
>> >>> regarding the move 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
>> >&g
Paolo Ciarrocchi wrote:
> On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty
> wrote:
>
> > 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 software project
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
Stefan Beller wrote:
> 2014-05-12 10:12 GMT+02:00 Felipe Contreras :
> > 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 ha
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.
Actual
Michael Haggerty 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 about a lack
of effo
t;
> 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.
You mention there are good technical arguments against the graduation of
the tools. Surely if you
ready
> > 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. Those arguments were discussed at
> length and I think their weight is on the side of not moving it. But
>
2014-05-12 10:12 GMT+02:00 Felipe Contreras :
> 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 are talking abou
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) reasons for keeping
git-remote-hg out of the core:
1. That subproject has not been m
Junio, can you answer 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 wo
is decision was my fault. Junio certainly hasn't
said so. You just have no idea what we are talking about.
> You make absolutely 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-re
fully 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 sufficientl
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 by
diff --git a/Documentation/git-remote-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 a
From: Daniel Liew
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.
Signed-off-by: Dan Liew
Signed
> 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
messag
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 resp
> 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 t
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 "unsubscrib
> 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 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 igno
> 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 si
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 rem
Daniel Liew 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 from the 'repo
ping.
On 21 February 2014 15:17, Daniel Liew 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
> '
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
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
this problem.
Signed-off-by: Brian Gernhardt
---
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-helpers/git-remote-hg
+++ b
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/remote-helpers/git-remote-hg
> +++
> On Mon, Jan 28, 2013 at 4:13 PM, Amit Bakshi 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 issu
out wrapper class. This patch 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-remo
[+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:
Greetings Git Developers,
I just used git-remote-hg to convert a small hg repository.
It worked perfectly.
Thanks, and happy hacking,
Samuel
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
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 that are
63 matches
Mail list logo
