* Ŭŭ letter
From: Usievaład Čorny @ 2012-10-31 14:39 UTC (permalink / raw)
To: git
Hello!
When I type comment message in Git Gui (1.8.0 and previous), I can't
use Ŭŭ letter (U+016C, U+016D) — it just transforms into simple Uu.
Please fix it.
--
Z pavahaj, Usievaład Čorny
^ permalink raw reply
* Re: Ŭŭ letter
From: Michael J Gruber @ 2012-10-31 14:57 UTC (permalink / raw)
To: Usievaład Čorny; +Cc: git
In-Reply-To: <CAG+H+KTc9trmR9VBgGsdHfAUFW8VMwa218O3yM_nyNWtrySXyg@mail.gmail.com>
Usievaład Čorny venit, vidit, dixit 31.10.2012 15:39:
> Hello!
>
> When I type comment message in Git Gui (1.8.0 and previous), I can't
> use Ŭŭ letter (U+016C, U+016D) — it just transforms into simple Uu.
> Please fix it.
Can you tell us more about your environment (LANG setting, OS)? I just
made two commits (1 with git-gui, one with git-commit on command line),
and both come out fine (LANG=de_DE.UTF-8, git version 1.8.0.226.gba44ac5
on Fedora 16):
git log -2 -p
commit 36de49231639eb9edccb1ebad595056d395141c7
Author: Michael J Gruber <git@drmicha.warpmail.net>
Date: Wed Oct 31 15:54:04 2012 +0100
äöüßŬŭ
diff --git a/a b/a
index 1074042..677c385 100644
--- a/a
+++ b/a
@@ -1 +1,2 @@
äöüßŬŭ
+äöüßŬŭ
commit cfcf8f021a53c1bf5ae018a723fbcfad8649a02b
Author: Michael J Gruber <git@drmicha.warpmail.net>
Date: Wed Oct 31 15:52:52 2012 +0100
äöüßŬŭ
diff --git a/a b/a
new file mode 100644
index 0000000..1074042
--- /dev/null
+++ b/a
@@ -0,0 +1 @@
+äöüßŬŭ
^ permalink raw reply related
* Re: Ŭŭ letter
From: Usievaład Čorny @ 2012-10-31 15:08 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <50913C58.2000200@drmicha.warpmail.net>
Ok. I use Win7 sp1, syslang — be_BY, git version 1.8.0.msysgit.0 („git
version“ command).
Problem appears when I type this letter on keyboard; when I copy-paste
it everyrhing is ok.
On Wed, Oct 31, 2012 at 5:57 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Usievaład Čorny venit, vidit, dixit 31.10.2012 15:39:
>> Hello!
>>
>> When I type comment message in Git Gui (1.8.0 and previous), I can't
>> use Ŭŭ letter (U+016C, U+016D) — it just transforms into simple Uu.
>> Please fix it.
>
> Can you tell us more about your environment (LANG setting, OS)? I just
> made two commits (1 with git-gui, one with git-commit on command line),
> and both come out fine (LANG=de_DE.UTF-8, git version 1.8.0.226.gba44ac5
> on Fedora 16):
>
> git log -2 -p
> commit 36de49231639eb9edccb1ebad595056d395141c7
> Author: Michael J Gruber <git@drmicha.warpmail.net>
> Date: Wed Oct 31 15:54:04 2012 +0100
>
> äöüßŬŭ
>
> diff --git a/a b/a
> index 1074042..677c385 100644
> --- a/a
> +++ b/a
> @@ -1 +1,2 @@
> äöüßŬŭ
> +äöüßŬŭ
>
> commit cfcf8f021a53c1bf5ae018a723fbcfad8649a02b
> Author: Michael J Gruber <git@drmicha.warpmail.net>
> Date: Wed Oct 31 15:52:52 2012 +0100
>
> äöüßŬŭ
>
> diff --git a/a b/a
> new file mode 100644
> index 0000000..1074042
> --- /dev/null
> +++ b/a
> @@ -0,0 +1 @@
> +äöüßŬŭ
--
Z pavahaj, Usievaład Čorny
^ permalink raw reply
* Re: Ŭŭ letter
From: Michael J Gruber @ 2012-10-31 15:15 UTC (permalink / raw)
To: Usievaład Čorny; +Cc: git
In-Reply-To: <CAG+H+KT=TyJ2hwWRxYwfXut==1v+a0fpy_pZH1SCR4=VukPHbQ@mail.gmail.com>
Usievaład Čorny venit, vidit, dixit 31.10.2012 16:08:
> Ok. I use Win7 sp1, syslang — be_BY, git version 1.8.0.msysgit.0 („git
> version“ command).
> Problem appears when I type this letter on keyboard; when I copy-paste
> it everyrhing is ok.
That is interesting. It means git-gui can make the commit properly, but
somehow the input method fails in the commit message form of the gui
window. Do those letters show correctly in the form (but fail to commit
correctly), or do they appear incorrectly already at the time you try to
type them?
That info could help windows folks find the cause.
Michael
> On Wed, Oct 31, 2012 at 5:57 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Usievaład Čorny venit, vidit, dixit 31.10.2012 15:39:
>>> Hello!
>>>
>>> When I type comment message in Git Gui (1.8.0 and previous), I can't
>>> use Ŭŭ letter (U+016C, U+016D) — it just transforms into simple Uu.
>>> Please fix it.
>>
>> Can you tell us more about your environment (LANG setting, OS)? I just
>> made two commits (1 with git-gui, one with git-commit on command line),
>> and both come out fine (LANG=de_DE.UTF-8, git version 1.8.0.226.gba44ac5
>> on Fedora 16):
>>
>> git log -2 -p
>> commit 36de49231639eb9edccb1ebad595056d395141c7
>> Author: Michael J Gruber <git@drmicha.warpmail.net>
>> Date: Wed Oct 31 15:54:04 2012 +0100
>>
>> äöüßŬŭ
>>
>> diff --git a/a b/a
>> index 1074042..677c385 100644
>> --- a/a
>> +++ b/a
>> @@ -1 +1,2 @@
>> äöüßŬŭ
>> +äöüßŬŭ
>>
>> commit cfcf8f021a53c1bf5ae018a723fbcfad8649a02b
>> Author: Michael J Gruber <git@drmicha.warpmail.net>
>> Date: Wed Oct 31 15:52:52 2012 +0100
>>
>> äöüßŬŭ
>>
>> diff --git a/a b/a
>> new file mode 100644
>> index 0000000..1074042
>> --- /dev/null
>> +++ b/a
>> @@ -0,0 +1 @@
>> +äöüßŬŭ
>
>
>
^ permalink raw reply
* Re: Ŭŭ letter
From: Usievaład Čorny @ 2012-10-31 15:27 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <5091407B.1080005@drmicha.warpmail.net>
No, commit is the same as input. Only when I press key combination for
Ŭŭ (AltGr+Uu [like AltGr+Cc for Ćć, this works]) — simple Uu appears
in text form. Every other special letter (Šš, Čč, Žž, Śś, Łł, Źź, Ćć)
works.
On Wed, Oct 31, 2012 at 6:15 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Usievaład Čorny venit, vidit, dixit 31.10.2012 16:08:
>> Ok. I use Win7 sp1, syslang — be_BY, git version 1.8.0.msysgit.0 („git
>> version“ command).
>> Problem appears when I type this letter on keyboard; when I copy-paste
>> it everyrhing is ok.
>
> That is interesting. It means git-gui can make the commit properly, but
> somehow the input method fails in the commit message form of the gui
> window. Do those letters show correctly in the form (but fail to commit
> correctly), or do they appear incorrectly already at the time you try to
> type them?
>
> That info could help windows folks find the cause.
>
> Michael
>
>> On Wed, Oct 31, 2012 at 5:57 PM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Usievaład Čorny venit, vidit, dixit 31.10.2012 15:39:
>>>> Hello!
>>>>
>>>> When I type comment message in Git Gui (1.8.0 and previous), I can't
>>>> use Ŭŭ letter (U+016C, U+016D) — it just transforms into simple Uu.
>>>> Please fix it.
>>>
>>> Can you tell us more about your environment (LANG setting, OS)? I just
>>> made two commits (1 with git-gui, one with git-commit on command line),
>>> and both come out fine (LANG=de_DE.UTF-8, git version 1.8.0.226.gba44ac5
>>> on Fedora 16):
>>>
>>> git log -2 -p
>>> commit 36de49231639eb9edccb1ebad595056d395141c7
>>> Author: Michael J Gruber <git@drmicha.warpmail.net>
>>> Date: Wed Oct 31 15:54:04 2012 +0100
>>>
>>> äöüßŬŭ
>>>
>>> diff --git a/a b/a
>>> index 1074042..677c385 100644
>>> --- a/a
>>> +++ b/a
>>> @@ -1 +1,2 @@
>>> äöüßŬŭ
>>> +äöüßŬŭ
>>>
>>> commit cfcf8f021a53c1bf5ae018a723fbcfad8649a02b
>>> Author: Michael J Gruber <git@drmicha.warpmail.net>
>>> Date: Wed Oct 31 15:52:52 2012 +0100
>>>
>>> äöüßŬŭ
>>>
>>> diff --git a/a b/a
>>> new file mode 100644
>>> index 0000000..1074042
>>> --- /dev/null
>>> +++ b/a
>>> @@ -0,0 +1 @@
>>> +äöüßŬŭ
>>
>>
>>
--
Z pavahaj, Usievaład Čorny
^ permalink raw reply
* Re: Ŭŭ letter
From: Michael J Gruber @ 2012-10-31 15:39 UTC (permalink / raw)
To: Usievaład Čorny; +Cc: git
In-Reply-To: <CAG+H+KSCuM0ZRhEvZJ1O9TFi9SBkDEi25tWn9r-DggWJnFRu1Q@mail.gmail.com>
Usievaład Čorny venit, vidit, dixit 31.10.2012 16:27:
> No, commit is the same as input. Only when I press key combination for
> Ŭŭ (AltGr+Uu [like AltGr+Cc for Ćć, this works]) — simple Uu appears
> in text form. Every other special letter (Šš, Čč, Žž, Śś, Łł, Źź, Ćć)
> works.
So it's really the input. Is AltGr+u maybe a menu shortcut in git gui
which overrides the special character? I think Ctril+u and such are
command shortcuts, and AltGr+u and such activate menus.
> On Wed, Oct 31, 2012 at 6:15 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Usievaład Čorny venit, vidit, dixit 31.10.2012 16:08:
>>> Ok. I use Win7 sp1, syslang — be_BY, git version 1.8.0.msysgit.0 („git
>>> version“ command).
>>> Problem appears when I type this letter on keyboard; when I copy-paste
>>> it everyrhing is ok.
>>
>> That is interesting. It means git-gui can make the commit properly, but
>> somehow the input method fails in the commit message form of the gui
>> window. Do those letters show correctly in the form (but fail to commit
>> correctly), or do they appear incorrectly already at the time you try to
>> type them?
>>
>> That info could help windows folks find the cause.
>>
>> Michael
>>
>>> On Wed, Oct 31, 2012 at 5:57 PM, Michael J Gruber
>>> <git@drmicha.warpmail.net> wrote:
>>>> Usievaład Čorny venit, vidit, dixit 31.10.2012 15:39:
>>>>> Hello!
>>>>>
>>>>> When I type comment message in Git Gui (1.8.0 and previous), I can't
>>>>> use Ŭŭ letter (U+016C, U+016D) — it just transforms into simple Uu.
>>>>> Please fix it.
>>>>
>>>> Can you tell us more about your environment (LANG setting, OS)? I just
>>>> made two commits (1 with git-gui, one with git-commit on command line),
>>>> and both come out fine (LANG=de_DE.UTF-8, git version 1.8.0.226.gba44ac5
>>>> on Fedora 16):
>>>>
>>>> git log -2 -p
>>>> commit 36de49231639eb9edccb1ebad595056d395141c7
>>>> Author: Michael J Gruber <git@drmicha.warpmail.net>
>>>> Date: Wed Oct 31 15:54:04 2012 +0100
>>>>
>>>> äöüßŬŭ
>>>>
>>>> diff --git a/a b/a
>>>> index 1074042..677c385 100644
>>>> --- a/a
>>>> +++ b/a
>>>> @@ -1 +1,2 @@
>>>> äöüßŬŭ
>>>> +äöüßŬŭ
>>>>
>>>> commit cfcf8f021a53c1bf5ae018a723fbcfad8649a02b
>>>> Author: Michael J Gruber <git@drmicha.warpmail.net>
>>>> Date: Wed Oct 31 15:52:52 2012 +0100
>>>>
>>>> äöüßŬŭ
>>>>
>>>> diff --git a/a b/a
>>>> new file mode 100644
>>>> index 0000000..1074042
>>>> --- /dev/null
>>>> +++ b/a
>>>> @@ -0,0 +1 @@
>>>> +äöüßŬŭ
>>>
>>>
>>>
>
>
>
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-10-31 15:39 UTC (permalink / raw)
To: Michael J Gruber
Cc: Johannes Schindelin, Jeff King, git, Junio C Hamano,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <5090EFCA.7070606@drmicha.warpmail.net>
Hi,
On Wed, Oct 31, 2012 at 10:30 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> [quotes heavily cut down by me]
> Felipe Contreras venit, vidit, dixit 30.10.2012 21:15:
>> On Tue, Oct 30, 2012 at 8:33 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>> On Tue, 30 Oct 2012, Felipe Contreras wrote:
>>>
>>>> But you mentioned something about cooperation, and I've yet to see how
>>>> is it that you are planning to cooperate. If you say you don't have time
>>>> to spend on this, I don't see why I should worry about testing this
>>>> series of patches.
>>>
>>> It has been mentioned before that the communication style including all
>>> these snarky and nasty comments is not helpful.
>>
>
> For the record, Johannes is not the only one being kept from looking at
> this series (further) by the tone of this discussion. Per hominem
> attacks are neither professional nor helpful. We prefer to discuss code
> here, just code.
Show me a "per hominem" attack coming from me. I never threw any such attacks.
Johannes is the one that complained about it, and that's the very
definition of *not* concentrating on the code, and discussing other
topics.
> The way other comment threads on this series
> unfolded made me choose to be a mere by-stander again.
This is precisely ad hominem; you are ignoring the code, not because
of the code, because of the person. This is as ad hominem as it gets.
As for how "professional or helpful" that is, it's debatable. The
Linux kernel mailing list is known for being harsh, and yet, they
manage to get more things done than any other. They truly look at the
code, just the code, they don't consider criticism to the code
personally (nobody should), nor linger on any personal beefs that only
distract from the end goal.
>>> and I've yet to see how is it that you are planning to cooperate.
>>
>> This is also a fact. You haven't provided a branch, you haven't reviewed
>> my implementation, you haven't tried it. You mentioned something about
>
> This does not become true through iteration. Max' recent post
Thee key word is _Max's_, not Johannes'. I never said nobody did, I
said Johannes didn't.
> 'On
> git-remote-hg (the "native" one)' [1] points at the msysgit wiki on
> remote-hg [2] and his remote-hg branch [3], which is based on and points
> at Sverre's original branch [4] and mine [5] which is [4] being
> regularly rebased on origin/next. The msysgit devel branch is in heavy
> use; I don't use mine often but run the test suite on every rebase
> before pushing out.
This is good information, why Johannes didn't provide it? It was easy
to copy-paste an URL. Lets suppose I did try this branch, and I come
up with a list of problems, Johannes could easily say; "I'm not
responsible for that code, I don't know what bugs could have been on
the rebase". Or something along those lines, which is potentially the
reason he didn't provide that.
But enough about Johannes, if I go on to Max's branch and give a try
to the code, make a list of issues, run my extensive tests and so on,
and make a report of the status, and a comparison with my code. Would
that make it more likely for you to stop being a by-stander?
Didn't think so. The truth of the matter is that it doesn't matter
what I do code-wise.
> If the issues that Sverre and Dscho tried to address with their git.git
> core (non-helper) patches turn out to be non-issues then I assume
> everyone will be happy, including them. You and they have thought a lot
> about these things and the way hg-git sync can work. There seems to be
> diagreement about the way fast-export/the remote helpers communicate
> which revs and refs that are to be synced and updated. This is not
> hg-specific, and I suggest to try and clarify that issue as thoroughly
> and calmly as possible. Everyone will benefit, and it will make clearer
> which tests are appropriate, and accordingly which fixes fix real problems.
I believe there is no disagreement any more, AFAICS my patches have
been accepted by Sverre and Jonathan... the commit messages is another
story. Johannes chose not to collaborate.
> Orthogonal to this, it seems that all hg-git interfaces could take
> advantage of a "git heads" feature if we resurrect the old ideas (can't
> find the thread right now).
Never heard of that.
You accused me of ad hominem, now I ask you; can you ignore any
personal biases and look at the code, and only at the code?
And finally, what do more do you expect me to do? About the code, and
only the code.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Michael J Gruber @ 2012-10-31 15:55 UTC (permalink / raw)
To: Felipe Contreras
Cc: Johannes Schindelin, Jeff King, git, Junio C Hamano,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <CAMP44s2a7fmxFmdn0CAcVtX8NxVtPdBKH9RY+i_Og53jb1Ju5Q@mail.gmail.com>
Felipe Contreras venit, vidit, dixit 31.10.2012 16:39:
> This is precisely ad hominem; you are ignoring the code, not because
> of the code, because of the person. This is as ad hominem as it gets.
I am not rejecting your code (I reviewed an early series) but reject the
communication style and manners displayed in this thread.
> As for how "professional or helpful" that is, it's debatable. The
> Linux kernel mailing list is known for being harsh, and yet, they
> manage to get more things done than any other. They truly look at the
> code, just the code, they don't consider criticism to the code
> personally (nobody should), nor linger on any personal beefs that only
> distract from the end goal.
There are people who choose not to be on that list because of its style.
For this list, I think we should follow this list's style, not that one.
> But enough about Johannes, if I go on to Max's branch and give a try
> to the code, make a list of issues, run my extensive tests and so on,
> and make a report of the status, and a comparison with my code. Would
> that make it more likely for you to stop being a by-stander?
Sure, that's what I and others have asked for.
> Didn't think so. The truth of the matter is that it doesn't matter
> what I do code-wise.
Just try, seriously.
>> Orthogonal to this, it seems that all hg-git interfaces could take
>> advantage of a "git heads" feature if we resurrect the old ideas (can't
>> find the thread right now).
>
> Never heard of that.
>
> You accused me of ad hominem, now I ask you; can you ignore any
> personal biases and look at the code, and only at the code?
My efforts here prove that I either have no biases or ignore them. I'm
not going to ignore the style of communication, though. As a patch
submitter, you ("generic you") want the attention of others as
reviewers. It's in your own (again "generic you") interest not to put
them off, in the same way as it's up to the submitter to argue why a
patch is desirable and correct.
Michael
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-10-31 15:58 UTC (permalink / raw)
To: Jeff King
Cc: git, Michael J Gruber, Johannes Schindelin, Junio C Hamano,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <20121031102712.GB30879@sigill.intra.peff.net>
On Wed, Oct 31, 2012 at 11:27 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Oct 31, 2012 at 10:30:50AM +0100, Michael J Gruber wrote:
>
>> For the record, Johannes is not the only one being kept from looking at
>> this series (further) by the tone of this discussion. Per hominem
>> attacks are neither professional nor helpful. We prefer to discuss code
>> here, just code. From my comments on an earlier version of your series
>> you can see I've tried. The way other comment threads on this series
>> unfolded made me choose to be a mere by-stander again.
>
> Me too. I really like some of the directions the series is taking, and
> as the maintainer, I'd like to pick it up. But there is a big question
> mark for me still about how it relates to the work in msysgit,
> especially:
>
> - What advantages does this implementation have over the one in
> msysgit (i.e., new features that the other one does not have)?
>From the top of my head:
* Support for tags
* Support for bookmarks
* Support for hg-git compatibility
* Extensive tests (truly extensive)
* _Much_ simpler code
* No dependencies
But let's forget about msysgit, because it's not really clear what
series of patches we are talking about. If we want to make a real try,
and a real comparison, we need a clear set of patches, which seem to
be available only on Max Horn's repo[1].
> - What disadvantages? If this implementation goes into git.git,
> the msysgit one is likely to wane in popularity. What will we be
> losing by doing so? If the answer is not "nothing", how hard would
> it be to port over the missing bits?
Honestly I am not aware of anything we would loose.
> - The msysgit one got held up by fixes needed for fast-export. Why
> aren't those a problem for this implementation? If we are using a
> different strategy that avoids the issue, what are the limitations
> (if any) of that strategy?
I explained that already. If indeed I was looking at the right
commits, then I already sent patches that tackle, or otherwise deal
with the very same problems (albet in much simpler way). These patches
should have held the code, as they are not _needed_ but merely
improving things. The rest of the patches would barely make any
difference.
This is of course my guess by reading the code, I have not tried it.
In short, only this patch helps:
http://article.gmane.org/gmane.comp.version-control.git/208729
And the rest of the code should work just fine on top of latest git.git.
> I have a feeling that some of those answers are buried deep within the
> discussion, but I have had a hard time following all of the back and
> forth due to the volume and tone of the discussion. Are we at a point
> now where some of the participants can try to summarize the situation?
Let me try to summarize the situation: Johannes is not willing to
collaborate, and nobody else has offered to push forward the patches
in msysgit.
> I am not saying that this implementation must be 100% better than the
> msysgit one. I do not want perfect to to be the enemy of good and end up
> with nothing. But at the same time, there really are two competing
> implementations, one of which has received substantially more field use.
> Even though the msysgit one is not in git.git, it seems like the path
> for making it happen exists (even if it has not been followed yet).
> Before merging an alternative implementation, I would want to know what
> we are potentially throwing away from the msysgit side, and make sure
> that we are not following a wrong path that msysgit has already tried
> and found to be lacking.
I also would like somebody to compare the two, so that we can have
healthy competition, and hopefully also cooperation. But that doesn't
seem to be likely.
So, what to do? Should I be the one making an analysis of that code?
Since nobody else is willing to try to compare the two, I don't see
many other choices, but when/if my conclusion is that my version is
superior, I presume nobody would take my word for it, so what would be
the point?
Cheers.
[1] http://github.com/fingolfin/git/tree/remote-hg
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-10-31 16:11 UTC (permalink / raw)
To: Michael J Gruber
Cc: Johannes Schindelin, Jeff King, git, Junio C Hamano,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <509149D9.3070606@drmicha.warpmail.net>
On Wed, Oct 31, 2012 at 4:55 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Felipe Contreras venit, vidit, dixit 31.10.2012 16:39:
>
>> This is precisely ad hominem; you are ignoring the code, not because
>> of the code, because of the person. This is as ad hominem as it gets.
>
> I am not rejecting your code (I reviewed an early series) but reject the
> communication style and manners displayed in this thread.
All right, you are not rejecting it, but you are staying away from it,
and presumably if it was coming from somebody else, you wouldn't.
>> As for how "professional or helpful" that is, it's debatable. The
>> Linux kernel mailing list is known for being harsh, and yet, they
>> manage to get more things done than any other. They truly look at the
>> code, just the code, they don't consider criticism to the code
>> personally (nobody should), nor linger on any personal beefs that only
>> distract from the end goal.
>
> There are people who choose not to be on that list because of its style.
> For this list, I think we should follow this list's style, not that one.
And what is this lists' style? I don't see any guidelines anywhere.
But my point wasn't that we should follow Linux's style, my point is
that it's debatable how one should engage in discussions.
And yet, I haven't seen where exactly did I throw those ad hominem
attacks. I can point you to where Johannes threw such attacks (or at
least snarky), to me, but I don't think that's relevant.
>> But enough about Johannes, if I go on to Max's branch and give a try
>> to the code, make a list of issues, run my extensive tests and so on,
>> and make a report of the status, and a comparison with my code. Would
>> that make it more likely for you to stop being a by-stander?
>
> Sure, that's what I and others have asked for.
Except nobody ever provided a link to the actual patches. You are the
first one to do so.
>> You accused me of ad hominem, now I ask you; can you ignore any
>> personal biases and look at the code, and only at the code?
>
> My efforts here prove that I either have no biases or ignore them. I'm
> not going to ignore the style of communication, though.
And yet earlier before you said in this list "we prefer to discuss the
code, just the code", and now you are saying you are not going to
ignore the style of communication, which is not code, and yet you are
discussing about it.
> As a patch
> submitter, you ("generic you") want the attention of others as
> reviewers. It's in your own (again "generic you") interest not to put
> them off, in the same way as it's up to the submitter to argue why a
> patch is desirable and correct.
Ah, so you are making me a favor by reviewing the code?
How about we concentrate on what's good for the project? Our users
don't care about petty personal beefs. Support to pull and push
mercurial repositories, _that_ they do care about.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: pre-receive hook output invalid characters
From: Erik Faye-Lund @ 2012-10-31 16:27 UTC (permalink / raw)
To: mnaoumov; +Cc: msysgit, GIT Mailing-list
In-Reply-To: <CABPQNSYj1-aaQieztkLxZjOhBQMqBJy+9POcmMcjGO4-a=EM9Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2592 bytes --]
On Wed, Oct 31, 2012 at 4:45 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> On Wed, Oct 31, 2012 at 4:24 PM, <mnaoumov@gmail.com> wrote:
>
>> If you add *pre-receive* hook in your git repository with the following
>> content
>>
>> #!/bin/sh
>>
>> echo Message
>> exit 1
>>
>> And then try to push you will get the following
>>
>> [image: Git Extensions push]<https://a248.e.akamai.net/camo.github.com/04b160d6fd381c09c7b0a9f30400e981a086fd46/687474703a2f2f692e696d6775722e636f6d2f4431714b722e706e67>
>>
>> The bug is about these strange 3 last characters.
>>
>> Recently I raised a bug for GitExtensions but it seems to be msysgit
>> issue as I could reproduce it from PowerShell as well
>>
>> https://github.com/gitextensions/gitextensions/issues/1313
>>
>>
> What you're seeing is most likely a CR (a carriage return character).
> Windows has CRLF new-lines, and Unix uses only LF.
>
> My guess is that echo produces CRLF, and this gets carried through and
> incorrecly displayed.
>
OK, I can reproduce it in Git Bash now, and by doing "git push 2>&1 | od
-c" I can see that I'm getting "Message\033[K\n".
This looks a little bit puzzling, but the sequence matches ANSI_SUFFIX in
sideband.c. So it seems this is intentional. This dates back to ebe8fa73.
I wonder, shouldn't we check isatty also before assuming ANSI-sequences?
---8<---
diff --git a/sideband.c b/sideband.c
index d5ffa1c..bd3e5a8 100644
--- a/sideband.c
+++ b/sideband.c
@@ -29,7 +29,7 @@ int recv_sideband(const char *me, int in_stream, int out)
memcpy(buf, PREFIX, pf);
term = getenv("TERM");
- if (term && strcmp(term, "dumb"))
+ if (isatty(out) && term && strcmp(term, "dumb"))
suffix = ANSI_SUFFIX;
else
suffix = DUMB_SUFFIX;
---8<---
Thoughts?
Unfortunately, I cannot reproduce it; all my attempts on using a local
> pre-receive hook seems to cause the following error:
>
> "error: cannot spawn hooks/pre-receive: No such file or directory"
>
> I have no clue why.
>
OK, that just me being stupid.
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
[-- Attachment #2: Type: text/html, Size: 6532 bytes --]
^ permalink raw reply related
* pre-receive hook output invalid characters
From: Erik Faye-Lund @ 2012-10-31 16:31 UTC (permalink / raw)
To: GIT Mailing-list; +Cc: Michael Naumov, msysgit
In-Reply-To: <CABPQNSZqNyKvFKoG6E0+JDaaNnUbWCaFH-WfKE1MicwDH-3TFA@mail.gmail.com>
Sorry for resending, but the previous version got dropped from the
main git mailing list due to a HTML-subpart. Converted to plain-text.
On Wed, Oct 31, 2012 at 4:45 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>
> On Wed, Oct 31, 2012 at 4:24 PM, <mnaoumov@gmail.com> wrote:
>>
>> If you add pre-receive hook in your git repository with the following
>> content
>>
>> #!/bin/sh
>>
>> echo Message
>> exit 1
>>
>> And then try to push you will get the following
>>
>> The bug is about these strange 3 last characters.
>>
>> Recently I raised a bug for GitExtensions but it seems to be msysgit
>> issue as I could reproduce it from PowerShell as well
>>
>> https://github.com/gitextensions/gitextensions/issues/1313
>
> What you're seeing is most likely a CR (a carriage return character).
> Windows has CRLF new-lines, and Unix uses only LF.
>
> My guess is that echo produces CRLF, and this gets carried through and
> incorrecly displayed.
OK, I can reproduce it in Git Bash now, and by doing "git push 2>&1 | od -c"
I can see that I'm getting "Message\033[K\n".
This looks a little bit puzzling, but the sequence matches ANSI_SUFFIX in
sideband.c. So it seems this is intentional. This dates back to ebe8fa73.
I wonder, shouldn't we check isatty also before assuming ANSI-sequences?
---8<---
diff --git a/sideband.c b/sideband.c
index d5ffa1c..bd3e5a8 100644
--- a/sideband.c
+++ b/sideband.c
@@ -29,7 +29,7 @@ int recv_sideband(const char *me, int in_stream, int out)
memcpy(buf, PREFIX, pf);
term = getenv("TERM");
- if (term && strcmp(term, "dumb"))
+ if (isatty(out) && term && strcmp(term, "dumb"))
suffix = ANSI_SUFFIX;
else
suffix = DUMB_SUFFIX;
---8<---
Thoughts?
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply related
* Re: [PATCH] parse_dirstat_params(): use string_list to split comma-separated string
From: Matt Kraai @ 2012-10-31 15:48 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121031140636.GA24291@sigill.intra.peff.net>
On Wed, Oct 31, 2012 at 10:06:36AM -0400, Jeff King wrote:
> On Tue, Oct 30, 2012 at 06:43:51PM +0000, Matt Kraai wrote:
>
> > Michael Haggerty <mhagger <at> alum.mit.edu> writes:
> > > + if (*params_copy)
> >
> > params_copy is set to the value returned by xstrdup, which cannot be NULL.
> > This check can be removed and if params_string can be NULL, it should be
> > checked before being passed to xstrdup.
>
> If you are referring to the last line, isn't it checking whether the
> string is empty, not NULL?
Oops, you're right. Sorry for misreading that.
--
Matt Kraai
https://ftbfs.org/kraai
^ permalink raw reply
* Strange line ending issue
From: Jie Zhang @ 2012-10-31 16:37 UTC (permalink / raw)
To: git
Hi,
I have a strange line ending issue with git. I'm not sure if it's a
bug or not. But it's really strange. Below are the steps to reproduce
what I saw:
1. $ git clone ssh://anonymous@firewall-sources.blackfin.uclinux.org:443/git/readonly-mirrors/toolchain.git
$ cd toolchain
2. $ git status
# On branch trunk
nothing to commit, working directory clean
3. $ rm -rf libusb/msvc/libusb.dsw
4. $ git checkout libusb/msvc/libusb.dsw
5. $ git status
# On branch trunk
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: libusb/msvc/libusb.dsw
#
no changes added to commit (use "git add" and/or "git commit -a")
6. $ git reset --hard
7. $ git status
# On branch trunk
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: libusb/msvc/libusb.dsw
#
no changes added to commit (use "git add" and/or "git commit -a")
8. libusb.dsw is in DOS format. I changed CR-LF to CR-CR-LF in
libusb.dsw with a tool I modified from dos2unix.
9. $ git status
# On branch trunk
nothing to commit, working directory clean
I tested with git 1.7.10.4 from Debian and git 1.8.0 built by myself.
Both have same result.
Thank you.
Jie
^ permalink raw reply
* Segmentation fault in git diff
From: aurelijus @ 2012-10-31 17:41 UTC (permalink / raw)
To: git
Hey,
I'm getting "Segmentation fault (core dumped)" when running command:
git diff -n1 -M -C -B --find-copies-harder --raw -t --abbrev=40
'd8c10caae6db3914695c3bc91cc7852777727625'^1
'd8c10caae6db3914695c3bc91cc7852777727625'
Here is full output - https://gist.github.com/d8f32227ea35488d9abc
I tried & got the error on 1.7.11.1, 1.7.12.3 & 1.8.0.
Server is RHEL 6.3
Repo config:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
Any ideas?
^ permalink raw reply
* Re: 'git describe' is very slow on development trees with lots of commits
From: Pavel Machek @ 2012-10-31 17:52 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Ahern, git, Arnaldo Carvalho de Melo, linux-kernel,
Andrew Vagin, Borislav Petkov, David Howells, Frederic Weisbecker,
Jiri Olsa, Namhyung Kim, Paul Mackerras, Peter Zijlstra,
Stephane Eranian, Steven Rostedt, arnaldo.melo,
Arnaldo Carvalho de Melo
In-Reply-To: <20121027133352.GB30001@gmail.com>
Hi!
> (Cc:-ed the Git development list.)
>
> * David Ahern <dsahern@gmail.com> wrote:
>
> > PERF-VERSION-GEN and specifically the git commands are the
> > cause of more delay than the config checks, especially when
> > doing the build in a VM with the kernel source on an NFS
> > mount.
>
> Yes, I have noticed that too.
....
> The cost on this pretty fast machine is about 1 msecs per commit
> - which adds up to about 2.5 seconds during much of the
> development cycle.
Well... I noticed my builds when little changed are very slow... and
it was due to the computation of version string. Ouch.
pavel@amd:~/mainline-altera/linux$ time git describe
fixes-for-linus-506-g71ca8691
0.68user 0.22system 27.82 (0m27.820s) elapsed 3.26%CPU
pavel@amd:~/mainline-altera/linux$
(Cached it is more reasonable 3 seconds, but it keeps going out of
cache all the time. Uncached clean build is 3 minutes, cached is 9
seconds + time to do git describe).
Thikpad X60.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH] test-lib: avoid full path to store test results
From: Johannes Sixt @ 2012-10-31 18:02 UTC (permalink / raw)
To: Felipe Contreras
Cc: Jonathan Nieder, git, Junio C Hamano, Jeff King,
Ævar Arnfjörð
In-Reply-To: <CAMP44s3WODA2Vru0Q1b5EWA6_1vdHnPmFfUmDg0Phh0S=76O9w@mail.gmail.com>
Am 31.10.2012 03:28, schrieb Felipe Contreras:
> On Wed, Oct 31, 2012 at 3:13 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Felipe Contreras wrote:
>>
>>> It's all fun and games to write explanations for things, but it's not
>>> that easy when you want those explanations to be actually true, and
>>> corrent--you have to spend time to make sure of that.
>>
>> That's why it's useful for the patch submitter to write them, asking
>> for help when necessary.
>>
>> As a bonus, it helps reviewers understand the effect of the patch.
>> Bugs averted!
>
> Yeah, that would be nice. Too bad I don't have that information, and
> have _zero_ motivation to go and get it for you.
Just to clarify: That information is not just for Jonathan, but for
everyone on this list and those who dig the history a year down the
road. Contributors who have _zero_ motiviation to find out that
information are not welcome here because they cause friction and take
away time from many others for _zero_ gain.
-- Hannes
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-10-31 18:04 UTC (permalink / raw)
To: Michael J Gruber
Cc: Johannes Schindelin, Jeff King, git, Junio C Hamano,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <509149D9.3070606@drmicha.warpmail.net>
On Wed, Oct 31, 2012 at 4:55 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Felipe Contreras venit, vidit, dixit 31.10.2012 16:39:
>> Didn't think so. The truth of the matter is that it doesn't matter
>> what I do code-wise.
>
> Just try, seriously.
All right.
First of all, I clone the repositories pointed out:
git://github.com/fingolfin/git.git (remote-hg)
git://github.com/mjg/git.git (remote-hg)
git://github.com/msysgit/git.git (d3ac32c^..1e000d4)
I rebase them on top ov v1.8.0... all 3 branches are different from
each other. I'll pick yours.
% git clone hg::~/dev/hg
Cloning into 'hg'...
Traceback (most recent call last):
File "/opt/git-2/libexec/git-core/git-remote-hg", line 101, in <module>
sys.exit(HgRemoteHelper().main(sys.argv))
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/helper.py",
line 196, in main
repo = self.get_repo(alias, url)
File "/opt/git-2/libexec/git-core/git-remote-hg", line 35, in get_repo
if repo.capable('branchmap'):
AttributeError: 'mqrepo' object has no attribute 'capable'
Let's try msysgit... The same.
Max's? The same.
Maybe it's just the setup and the tests actually pass?
# failed 11 among 14 test(s)
Nope.
All right, it probably doesn't work with recent versions of mercurial.
Let's try with hg v2.2:
# failed 4 among 14 test(s)
All right, that's progress.
Can I clone now?
% git clone hg::~/dev/hg
Cloning into 'hg'...
progress Exported revision 0.
progress Exported revision 1000.
fatal: Missing space before < in ident string: Anupam
Kapoor<anupam.kapoor@gmail.com> <none@none> 1127407335 -0700
fast-import: dumping crash report to /tmp/hg/.git/fast_import_crash_18197
fatal: Error while running fast-import
Traceback (most recent call last):
File "/opt/git-2/libexec/git-core/git-remote-hg", line 101, in <module>
sys.exit(HgRemoteHelper().main(sys.argv))
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/helper.py",
line 204, in main
more = self.read_one_line(repo)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/helper.py",
line 169, in read_one_line
func(repo, cmdline)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/helper.py",
line 108, in do_import
repo.exporter.export_repo(repo.gitdir, refs)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/exporter.py",
line 27, in export_repo
exporter.export_repo(refs)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py",
line 246, in export_repo
exported = self.export_revision(ctx) or exported
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py",
line 215, in export_revision
self.export_files(ctx)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py",
line 190, in export_files
self.write_file(ctx, name, idnum)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py",
line 105, in write_file
self.write_blob(data, idnum)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py",
line 99, in write_blob
self.write_data(data)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py",
line 91, in write_data
self.write(data, LF)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py",
line 52, in write
sys.stdout.write(msg)
IOError: [Errno 32] Broken pipe
Nope.
All right, let's go back to hg v1.9 (Jun 2011).
# passed all 14 test(s)
Yay!
% git clone hg::~/dev/hg
Cloning into 'hg'...
progress Exported revision 0.
progress Exported revision 1000.
fatal: Missing space before < in ident string: Anupam
Kapoor<anupam.kapoor@gmail.com> <none@none> 1127407335 -0700
fast-import: dumping crash report to /tmp/hg/.git/fast_import_crash_18646
fatal: Error while running fast-import
Traceback (most recent call last):
File "/opt/git-2/libexec/git-core/git-remote-hg", line 101, in
<module>
sys.exit(HgRemoteHelper().main(sys.argv))
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/helper.py",
line 204, in main
more = self.read_one_line(repo)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/helper.py",
line 169, in read_one_line
func(repo, cmdline)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/helper.py",
line 108, in do_import
repo.exporter.export_repo(repo.gitdir, refs)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/exporter.py",
line 27, in export_repo
exporter.export_repo(refs)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py",
line 246, in export_repo
exported = self.export_revision(ctx) or exported
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py",
line 215, in export_revision
self.export_files(ctx)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py",
line 190, in export_files
self.write_file(ctx, name, idnum)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py",
line 105, in write_file
self.write_blob(data, idnum)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py",
line 99, in write_blob
self.write_data(data)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py",
line 91, in write_data
self.write(data, LF)
File "/opt/git-2/lib/python2.7/site-packages/git_remote_helpers/hg/hgexport.py",
line 52, in write
sys.stdout.write(msg)
IOError: [Errno 32] Broken pipe
Still doesn't work.
Let's try msysgit.
% git clone hg::~/dev/hg
Cloning into 'hg'...
progress Exported revision 0.
progress Exported revision 1000.
progress Exported revision 2000.
progress Exported revision 3000.
progress Exported revision 4000.
progress Exported revision 5000.
progress Exported revision 6000.
progress Exported revision 7000.
progress Exported revision 8000.
progress Exported revision 9000.
progress Exported revision 10000.
progress Exported revision 11000.
progress Exported revision 12000.
progress Exported revision 13000.
progress Exported revision 14000.
progress Exported revision 15000.
progress Exported revision 16000.
progress Exported revision 17000.
Finally!
Let's run my tests:
test.sh:
# failed 1 among 1 test(s)
test-bidi.sh:
# failed 5 among 6 test(s)
test-hg-git.sh
# failed 9 among 10 test(s)
Other than the setup tests which really don't exercise any code, all
the tests fail.
And it's not only a silly error like couldn't find remote-hg; the
tests do really fail:
Traceback (most recent call last):
File "/home/felipec/dev/git-other-remote-hg/git-remote-hg", line
101, in <module>
sys.exit(HgRemoteHelper().main(sys.argv))
File "/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/helper.py",
line 204, in main
more = self.read_one_line(repo)
File "/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/helper.py",
line 169, in read_one_line
func(repo, cmdline)
File "/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/helper.py",
line 122, in do_export
localrepo.importer.do_import(localrepo.gitdir)
File "/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/hg/importer.py",
line 27, in do_import
processor.parseMany(sources, parser.ImportParser, procc)
File "/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/fastimport/processor.py",
line 219, in parseMany
processor.process(parser.parse())
File "/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/fastimport/processor.py",
line 76, in process
handler(self, cmd)
File "/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/hg/hgimport.py",
line 262, in commit_handler
self.idmap[cmd.id] = self.putcommit(modified, modes, copies, cmt)
File "/home/felipec/dev/git-other-remote-hg/t/../git_remote_helpers/build/lib/git_remote_helpers/hg/hgimport.py",
line 294, in putcommit
self.repo.commitctx(ctx)
File "/home/felipec/dev/hg/mercurial/localrepo.py", line 1112, in commitctx
user, ctx.date(), ctx.extra().copy())
File "/home/felipec/dev/hg/mercurial/changelog.py", line 213, in add
user, desc = encoding.fromlocal(user), encoding.fromlocal(desc)
File "/home/felipec/dev/hg/mercurial/encoding.py", line 133, in fromlocal
raise error.Abort("decoding near '%s': %s!" % (sub, inst))
mercurial.error.Abort: decoding near 'add älphà
': 'ascii' codec can't decode byte 0xc3 in position 4: ordinal not in
range(128)!
Let's gather what we have:
* msysgit: works in hg v2.2, but not hg v2.3
* yours: kind of works on hg v1.9, but not really
* Max's: works on hg v2.2, but not hg v2.3
None of them pass even one of my tests.
Now lets remove all the supposed required patches to git core:
# passed all 14 test(s)
But that doesn't really say much, these tests are _really_ simple.
How about performance?
Performance counter stats for 'git clone hg::~/dev/hg':
241391.332748 task-clock # 1.387 CPUs utilized
53,357 context-switches # 0.221 K/sec
3,797 CPU-migrations # 0.016 K/sec
1,258,346 page-faults # 0.005 M/sec
433,914,358,895 cycles # 1.798 GHz
185,410,787,111 stalled-cycles-frontend # 42.73% frontend cycles idle
<not supported> stalled-cycles-backend
581,663,561,600 instructions # 1.34 insns per cycle
# 0.32 stalled cycles per insn
101,993,199,721 branches # 422.522 M/sec
5,208,212,657 branch-misses # 5.11% of all branches
174.038642915 seconds time elapsed
Compared to;
Performance counter stats for 'git clone hg::~/dev/hg':
412892.981091 task-clock # 1.211 CPUs utilized
200,029 context-switches # 0.484 K/sec
9,288 CPU-migrations # 0.022 K/sec
632,783 page-faults # 0.002 M/sec
741,785,312,967 cycles # 1.797 GHz
306,533,270,745 stalled-cycles-frontend # 41.32% frontend cycles idle
<not supported> stalled-cycles-backend
1,012,488,224,809 instructions # 1.36 insns per cycle
# 0.30 stalled cycles per insn
168,056,255,731 branches # 407.021 M/sec
9,528,432,325 branch-misses # 5.67% of all branches
340.976843750 seconds time elapsed
Looks like there's something to improve in this area, but I wouldn't
be surprised if the reason for the better performance is that
something is not being done. I'll investigate.
And all this for the low price of:
.gitignore | 1 +
Makefile | 1 +
git-remote-hg.py | 101 +++++++++++
git-remote-testgit.py | 295
++++++------------------------
git_remote_helpers/fastimport/commands.py | 469
+++++++++++++++++++++++++++++++++++++++++++++++
git_remote_helpers/fastimport/dates.py | 79 ++++++++
git_remote_helpers/fastimport/errors.py | 182 +++++++++++++++++++
git_remote_helpers/fastimport/head_tracker.py | 47 +++++
git_remote_helpers/fastimport/helpers.py | 88 +++++++++
git_remote_helpers/fastimport/idmapfile.py | 65 +++++++
git_remote_helpers/fastimport/parser.py | 621
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
git_remote_helpers/fastimport/processor.py | 222 +++++++++++++++++++++++
git_remote_helpers/git/importer.py | 30 +--
git_remote_helpers/git/repo.py | 8 +-
git_remote_helpers/helper.py | 207 +++++++++++++++++++++
git_remote_helpers/hg/exporter.py | 29 +++
git_remote_helpers/hg/hg.py | 126 +++++++++++++
git_remote_helpers/hg/hgexport.py | 280
++++++++++++++++++++++++++++
git_remote_helpers/hg/hgimport.py | 401
+++++++++++++++++++++++++++++++++++++++++
git_remote_helpers/hg/importer.py | 29 +++
git_remote_helpers/hg/non_local.py | 51 ++++++
git_remote_helpers/hg/util.py | 14 ++
git_remote_helpers/setup.py | 3 +-
t/t5800-remote-helpers.sh | 19 ++
t/t5801-remote-hg.sh | 143 +++++++++++++++
25 files changed, 3242 insertions(+), 269 deletions(-)
Compared to:
contrib/remote-hg/Makefile | 13 ++
contrib/remote-hg/git-remote-hg | 780
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
contrib/remote-hg/test-bidi.sh | 241 ++++++++++++++++++++++++
contrib/remote-hg/test-hg-git.sh | 464
+++++++++++++++++++++++++++++++++++++++++++++
contrib/remote-hg/test.sh | 45 +++++
5 files changed, 1543 insertions(+)
Now, sure, I am biased, but the truth is I don't know of a single
feature that this remote-hg supports that my version doesn't. If
there's any, I'm all ears; I'll implement it right away.
At no point in time did I ever suggested this code to be thrown away,
but if there's any possibility salvaging some of this code, they only
way I see it is if I myself do it, because nobody has stepped up to
work on this. And quite frankly, I think I've already done more than
enough, so...
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Johannes Schindelin @ 2012-10-31 18:20 UTC (permalink / raw)
To: Jeff King
Cc: git, Michael J Gruber, Felipe Contreras, Junio C Hamano,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <20121031102712.GB30879@sigill.intra.peff.net>
Hi Peff,
On Wed, 31 Oct 2012, Jeff King wrote:
> I really like some of the directions the series is taking, and as the
> maintainer, I'd like to pick it up.
Code-wise, I agree.
> But there is a big question mark for me still about how it relates to
> the work in msysgit, especially:
>
> - What advantages does this implementation have over the one in
> msysgit (i.e., new features that the other one does not have)?
Disclaimer: I do not know the details (as I said, I have higher priorities
elsewhere since the remote-hg I need for everyday work continues to do its
job, and the patch series bringing Python to msysGit is more pressing,
and I will enjoy its review much more, too).
The biggest advantage seems to me that it was started later than msysGit's
remote-hg and as such could potentially exploit recent improvements in
git.git.
> - What disadvantages? If this implementation goes into git.git,
> the msysgit one is likely to wane in popularity. What will we be
> losing by doing so? If the answer is not "nothing", how hard would
> it be to port over the missing bits?
The biggest advantage msysGit's series has is that it had a fix for a
fundamental flaw in fast-export. Fast-export was intended to work
incrementally, so the incantation "git branch blub master && git
fast-export ^master blub" is expected to update the ref "blub" properly.
I just tested this with junio/next and it seems this issue is still
unfixed: instead of
reset refs/heads/blub
from e7510461b7db54b181d07acced0ed3b1ada072c8
I get
reset refs/heads/blub
from :0
when running "git fast-export ^master blub".
Having said that, we have no problem to throw away the fix that was
rejected by Junio (who wanted something much more general which I refused
to implement both due to lack of time and lack of need -- think YAGNI) and
rebase our stuff on top of whatever goes into git.git's next (or master,
we are still deciding in the msysGit project whether we should stop
tracking next).
Another thing that I really like about remote-hg as it is in msysGit is
that it was designed with extensibility in mind. It should not be too hard
to support other fast-import/export based backends using that
infrastructure. I am particularly interested in bzr myself, but there is
no day-job related project I could use as an excuse to give that project
a higher priority that the other things I am doing at the moment.
> - The msysgit one got held up by fixes needed for fast-export. Why
> aren't those a problem for this implementation? If we are using a
> different strategy that avoids the issue, what are the limitations (if
> any) of that strategy?
Junio wanted a more general solution, adding infrastructure to the
rev-list engine that I did not need -- and did not see the need for,
either -- and given the amount of time I had invested in a working
remote-hg and given that I needed it desperately for my day-job project, I
decided to just put it into msysGit and give up my hopes for it to become
official.
It has worked well in the meantime and met my needs. The only thing
missing is the support for octopus merges. But I would need that only to
satisfy my geek self: I would set up an automatic Hg mirror of git.git
itself on bitbucket.
> I have a feeling that some of those answers are buried deep within the
> discussion, but I have had a hard time following all of the back and
> forth due to the volume and tone of the discussion. Are we at a point
> now where some of the participants can try to summarize the situation?
Hopefully my attempt met your expectations.
Thank you,
Dscho
^ permalink raw reply
* Re: [PATCH] test-lib: avoid full path to store test results
From: Felipe Contreras @ 2012-10-31 18:28 UTC (permalink / raw)
To: Johannes Sixt
Cc: Jonathan Nieder, git, Junio C Hamano, Jeff King,
Ævar Arnfjörð
In-Reply-To: <509167C8.6090600@kdbg.org>
On Wed, Oct 31, 2012 at 7:02 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> Am 31.10.2012 03:28, schrieb Felipe Contreras:
>> Yeah, that would be nice. Too bad I don't have that information, and
>> have _zero_ motivation to go and get it for you.
>
> Just to clarify: That information is not just for Jonathan, but for
> everyone on this list and those who dig the history a year down the
> road.
Information that nobody has requested but Johannes.
> Contributors who have _zero_ motiviation to find out that
> information are not welcome here because they cause friction and take
> away time from many others for _zero_ gain.
Fine, stay with the broken code.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-10-31 18:41 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, git, Michael J Gruber, Junio C Hamano,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <alpine.DEB.1.00.1210311900450.7256@s15462909.onlinehome-server.info>
Hi,
On Wed, Oct 31, 2012 at 7:20 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> - What disadvantages? If this implementation goes into git.git,
>> the msysgit one is likely to wane in popularity. What will we be
>> losing by doing so? If the answer is not "nothing", how hard would
>> it be to port over the missing bits?
>
> The biggest advantage msysGit's series has is that it had a fix for a
> fundamental flaw in fast-export. Fast-export was intended to work
> incrementally, so the incantation "git branch blub master && git
> fast-export ^master blub" is expected to update the ref "blub" properly.
>
> I just tested this with junio/next and it seems this issue is still
> unfixed: instead of
>
> reset refs/heads/blub
> from e7510461b7db54b181d07acced0ed3b1ada072c8
>
> I get
>
> reset refs/heads/blub
> from :0
>
> when running "git fast-export ^master blub".
That is not a problem. It has been discussed extensively, and the
consensus seems to be that such command should throw nothing:
http://article.gmane.org/gmane.comp.version-control.git/208729
But that doesn't affect remote helpers, what we _really_ want is for
this to work:
git fast-export --import-marks=tmp-marks \
--export-marks=tmp-marks master > /dev/null &&
git fast-export --import-marks=tmp-marks \
--export-marks=tmp-marks blub > actual &&
And that's fixed in this patch: (for which the consensus seems to be
that it's also OK)
http://article.gmane.org/gmane.comp.version-control.git/208730
But none of these patches are *required* for remote-hg (any of them) to work.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Jonathan Nieder @ 2012-10-31 18:59 UTC (permalink / raw)
To: Felipe Contreras
Cc: Johannes Schindelin, Jeff King, git, Michael J Gruber,
Junio C Hamano, Sverre Rabbelier, Ilari Liusvaara,
Daniel Barkalow
In-Reply-To: <CAMP44s2y-co4TELg28==axRmbF7xq3Qp7U8wjg6XtGAUMgf40w@mail.gmail.com>
Felipe Contreras wrote:
> On Wed, Oct 31, 2012 at 7:20 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> I just tested this with junio/next and it seems this issue is still
>> unfixed: instead of
>>
>> reset refs/heads/blub
>> from e7510461b7db54b181d07acced0ed3b1ada072c8
>>
>> I get
>>
>> reset refs/heads/blub
>> from :0
>>
>> when running "git fast-export ^master blub".
>
> That is not a problem. It has been discussed extensively, and the
> consensus seems to be that such command should throw nothing:
>
> http://article.gmane.org/gmane.comp.version-control.git/208729
Um. Are you claiming I have said that "git fast-export ^master blub"
should silently emit nothing? Or has this been discussed extensively
with someone else?
Jonathan
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-10-31 19:24 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Johannes Schindelin, Jeff King, git, Michael J Gruber,
Junio C Hamano, Sverre Rabbelier, Ilari Liusvaara,
Daniel Barkalow
In-Reply-To: <20121031185903.GA1480@elie.Belkin>
Hi,
On Wed, Oct 31, 2012 at 7:59 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>> On Wed, Oct 31, 2012 at 7:20 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>
>>> I just tested this with junio/next and it seems this issue is still
>>> unfixed: instead of
>>>
>>> reset refs/heads/blub
>>> from e7510461b7db54b181d07acced0ed3b1ada072c8
>>>
>>> I get
>>>
>>> reset refs/heads/blub
>>> from :0
>>>
>>> when running "git fast-export ^master blub".
>>
>> That is not a problem. It has been discussed extensively, and the
>> consensus seems to be that such command should throw nothing:
>>
>> http://article.gmane.org/gmane.comp.version-control.git/208729
>
> Um. Are you claiming I have said that "git fast-export ^master blub"
> should silently emit nothing? Or has this been discussed extensively
> with someone else?
Maybe I misunderstood when you said:
> A patch meeting the above description would make perfect sense to me.
Anyway, when you have:
% git fast-export ^next next^{commit}
# nothing
% git fast-export ^next next~0
# nothing
% git fast-export ^next next~1
# nothing
% git fast-export ^next next~2
# nothing
It only makes sense that:
% git fast-export ^next next
# nothing
It doesn't get any more obvious than that. But to each his own.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-10-31 19:47 UTC (permalink / raw)
To: Michael J Gruber
Cc: Johannes Schindelin, Jeff King, git, Junio C Hamano,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <CAMP44s2oKMog5GygrAag8SOdwhQJr4gCZxZAwWUo-ERDzni0ag@mail.gmail.com>
On Wed, Oct 31, 2012 at 7:04 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> How about performance?
> 174.038642915 seconds time elapsed
>
> Compared to;
> 340.976843750 seconds time elapsed
>
> Looks like there's something to improve in this area, but I wouldn't
> be surprised if the reason for the better performance is that
> something is not being done. I'll investigate.
Turns out msysgit's remote-hg is not exporting the whole repository,
that's why it's faster =/
Let's try with a smaller repo:
Performance counter stats for 'git clone hg::~/dev/love love-2':
16130.554299 task-clock # 1.311 CPUs utilized
5,625 context-switches # 0.349 K/sec
241 CPU-migrations # 0.015 K/sec
84,042 page-faults # 0.005 M/sec
28,985,094,782 cycles # 1.797 GHz
12,235,424,421 stalled-cycles-frontend # 42.21% frontend cycles idle
<not supported> stalled-cycles-backend
38,762,850,763 instructions # 1.34 insns per cycle
# 0.32 stalled cycles per insn
6,727,815,043 branches # 417.085 M/sec
354,887,290 branch-misses # 5.27% of all branches
12.300536156 seconds time elapsed
And mine:
Performance counter stats for 'git clone hg::~/dev/love love-1':
16116.643370 task-clock # 1.295 CPUs utilized
6,270 context-switches # 0.389 K/sec
183 CPU-migrations # 0.011 K/sec
57,767 page-faults # 0.004 M/sec
28,962,073,772 cycles # 1.797 GHz
11,844,122,698 stalled-cycles-frontend # 40.90% frontend cycles idle
<not supported> stalled-cycles-backend
39,679,556,857 instructions # 1.37 insns per cycle
# 0.30 stalled cycles per insn
6,609,397,307 branches # 410.098 M/sec
371,092,848 branch-misses # 5.61% of all branches
12.446643210 seconds time elapsed
That's more like it. msysgit's is still missing a few commits, but
nothing mayor.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: Johannes Schindelin @ 2012-10-31 20:28 UTC (permalink / raw)
To: Felipe Contreras
Cc: Jonathan Nieder, Jeff King, git, Michael J Gruber, Junio C Hamano,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <CAMP44s2-UoT03OeTmM9=nh9wCUt84exPNuHyuThp=WQkxvCNLQ@mail.gmail.com>
Hi,
On Wed, 31 Oct 2012, Felipe Contreras wrote:
> It doesn't get any more obvious than that. But to each his own.
In my opinion, Jonathan does not deserve any of such condescending words.
But maybe the Git maintainers are okay with such a tone on this list?
Hth,
Johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox