* 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: [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: 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: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: Ŭŭ 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: Ŭŭ 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: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: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 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
* Ŭŭ 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: Git clone fails with "bad pack header", how to get remote log
From: kevin molcard @ 2012-10-31 14:34 UTC (permalink / raw)
To: Jeff King
Cc: Konstantin Khomoutov, git-users-/JYPxA39Uh5TLH3MbocFFw,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20121031141955.GC24291-bBVMEuqLR+SYVEpFpFwlB0AkDMvbqDRI@public.gmane.org>
I forgot to mention that I am using scm manager:
https://bitbucket.org/sdorra/scm-manager/wiki/Home
So that maybe the " custom layer you are talking about.
Kevin
On 10/31/12 3:19 PM, Jeff King wrote:
> On Tue, Oct 30, 2012 at 03:57:36PM +0100, kevin molcard wrote:
>
>> I tried to install git 1.8 on the remote server and get exactly the
>> same problem :(.
>> [...]
>>>> Sometimes (very often when several git clone are sent at the same
>>>> time), I have the following error:
>>>> remote: internal server error
>>>> fatal: protocol error: bad pack header
> I'm very confused about who is printing "internal server error". The
> "remote:" indicates that it came to the git client via the sideband,
> which means it probably came from the stderr of a child process (e.g.,
> pack-objects). But git does not and has never generated the phrase
> "internal server error".
>
> So what program is producing that? Is there some kind of custom layer
> that might be run when upload-pack runs "git pack-objects ..."? Can you
> try running strace on the server?
>
> -Peff
>
--
^ permalink raw reply
* Re: Git clone fails with "bad pack header", how to get remote log
From: kevin molcard @ 2012-10-31 14:25 UTC (permalink / raw)
To: Jeff King
Cc: Konstantin Khomoutov, git-users-/JYPxA39Uh5TLH3MbocFFw,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20121031141955.GC24291-bBVMEuqLR+SYVEpFpFwlB0AkDMvbqDRI@public.gmane.org>
Yes I can,
can you tell me how I have to do that?
thanks
Kevin
On 10/31/12 3:19 PM, Jeff King wrote:
> On Tue, Oct 30, 2012 at 03:57:36PM +0100, kevin molcard wrote:
>
>> I tried to install git 1.8 on the remote server and get exactly the
>> same problem :(.
>> [...]
>>>> Sometimes (very often when several git clone are sent at the same
>>>> time), I have the following error:
>>>> remote: internal server error
>>>> fatal: protocol error: bad pack header
> I'm very confused about who is printing "internal server error". The
> "remote:" indicates that it came to the git client via the sideband,
> which means it probably came from the stderr of a child process (e.g.,
> pack-objects). But git does not and has never generated the phrase
> "internal server error".
>
> So what program is producing that? Is there some kind of custom layer
> that might be run when upload-pack runs "git pack-objects ..."? Can you
> try running strace on the server?
>
> -Peff
>
--
^ permalink raw reply
* Fwd: Re: [git-users] Git clone fails with "bad pack header", how to get remote log
From: kevin molcard @ 2012-10-31 14:20 UTC (permalink / raw)
To: git
In-Reply-To: <20121031152837.4c0f8ce84fae14ba36429605@domain007.com>
Hi all again,
here is my second email :).
It contains the git versions in my system.
FYI, I updated git to 1.8.0 on my remote but still having the same issue.
Another thing that might be interesting is that it seems to happen only
when cloning from Windows build machine (i.e. I send 2 clone command on
from the mac and 2 from the Windows and it seems to always fails on the
Windows).
Thanks again
Kevin
-------- Original Message --------
Subject: Re: [git-users] Git clone fails with "bad pack header", how to
get remote log
Date: Wed, 31 Oct 2012 15:28:37 +0400
From: Konstantin Khomoutov <flatworm@users.sourceforge.net>
To: kevin molcard <kev2041@gmail.com>
CC: git-users@googlegroups.com
On Tue, 30 Oct 2012 08:01:12 +0100
kevin molcard <kev2041@gmail.com> wrote:
> thanks for the reply.
> The versions of git are:
> - on remote: 1.5.6.5
> - on windows build machine: 1.7.11.msysgit.1
> - on mac build machine: 1.7.3.4
>
> I will try to install latest git version on my remote server and get
> back to you.
Hi, Kevin.
I noticed my Cc'ed messages did not reach the main Git list for some
reason (even though I did see these my messages coming from the
list-management software), and the did not show up on Gmane [1].
I do not know what's the reason is, so please try forwarding my first
reply to your original message and the message I'm replying to now
(with versions of software involved) to that list yourself -- maybe
you'll be more lucky.
Sorry for the delay.
1. http://thread.gmane.org/gmane.comp.version-control.git/
^ permalink raw reply
* Re: [git-users] Git clone fails with "bad pack header", how to get remote log
From: Jeff King @ 2012-10-31 14:19 UTC (permalink / raw)
To: kevin molcard; +Cc: Konstantin Khomoutov, git-users, git
In-Reply-To: <508FEAE0.20204@gmail.com>
On Tue, Oct 30, 2012 at 03:57:36PM +0100, kevin molcard wrote:
> I tried to install git 1.8 on the remote server and get exactly the
> same problem :(.
> [...]
> >>Sometimes (very often when several git clone are sent at the same
> >>time), I have the following error:
> >> remote: internal server error
> >> fatal: protocol error: bad pack header
I'm very confused about who is printing "internal server error". The
"remote:" indicates that it came to the git client via the sideband,
which means it probably came from the stderr of a child process (e.g.,
pack-objects). But git does not and has never generated the phrase
"internal server error".
So what program is producing that? Is there some kind of custom layer
that might be run when upload-pack runs "git pack-objects ..."? Can you
try running strace on the server?
-Peff
^ permalink raw reply
* Fwd: Re: [git-users] Git clone fails with "bad pack header", how to get remote log
From: kevin molcard @ 2012-10-31 14:17 UTC (permalink / raw)
To: git
In-Reply-To: <20121029211854.b58c791d30a6c8d68665e574@domain007.com>
Hi all,
I am forwarding a reply I got from a message I sent to git user mailing
list because of a "bad pack header error" (more information below).
I will forward another email where I give all the git versions of my system.
Any clue on this would be much appreciated.
Thanks in advance
Kevin
-------- Original Message --------
Subject: Re: [git-users] Git clone fails with "bad pack header", how to
get remote log
Date: Mon, 29 Oct 2012 21:18:54 +0400
From: Konstantin Khomoutov <flatworm@users.sourceforge.net>
To: git-users@googlegroups.com
CC: Kevin Molcard <kev2041@gmail.com>, git@vger.kernel.org
On Mon, 29 Oct 2012 09:52:54 -0700 (PDT)
Kevin Molcard <kev2041@gmail.com> wrote:
> I have a problem with my build system.
>
> I have a remote server with a relatively large repository (around 12
> GB, each branch having a size of 3 GB).
>
> I have also 2 build servers (Mac, Windows) that are cloning the repo
> from the remote.
>
> Sometimes (very often when several git clone are sent at the same
> time), I have the following error:
>
> remote: internal server error
> fatal: protocol error: bad pack header
>
> I know that it happens when the remote is compressing objects (thanks
> to `--progress -v` flags) because the last line of the log before the
> erro is:
> remote: Compressing objects: 93% (17959/19284) [K
>
> * So I have 2 questions, does anybody what is the problem and what
> should I do?
> * Is there a way to get a more precise log from the remote to debug
> this problem?
This reminds me of a bug fixed in 1.7.12.1 [1]:
* When "git push" triggered the automatic gc on the receiving end, a
message from "git prune" that said it was removing cruft leaked to
the standard output, breaking the communication protocol.
In any case, bugs should be reported to the main Git list (which is
git at vger.kernel.org), not here.
I'm Cc'ing the main Git list so you'll get any responses from there, if
any.
Kevin, please answer to this message (keeping all the Ccs -- use "Reply
to group" or "Reply to all" in your MUA) and describe exactly what Git
versions on which platforms your have.
1. https://raw.github.com/git/git/master/Documentation/RelNotes/1.7.12.1.txt
^ permalink raw reply
* Re: [PATCH v6 2/3] completion: add new __gitcompadd helper
From: SZEDER Gábor @ 2012-10-31 14:15 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Jeff King, Matthieu Moy
In-Reply-To: <CAMP44s0dctpjobNNRTOFcX4ir+nzenTZMNWFbEvBa-QU93psbA@mail.gmail.com>
On Wed, Oct 31, 2012 at 12:05:34AM +0100, Felipe Contreras wrote:
> On Tue, Oct 30, 2012 at 11:58 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
> > On Mon, Oct 22, 2012 at 03:45:41AM +0200, Felipe Contreras wrote:
> >> The idea is to never touch the COMPREPLY variable directly.
> >>
> >> This allows other completion systems override __gitcompadd, and do
> >> something different instead.
> >>
> >> Also, this allows the simplification of the completion tests (separate
> >> patch).
> >
> > This doesn't apply anymore, does it? The mentioned simplification is
> > done in the other series.
>
> Yeah, but you mentioned you didn't like all the COMPREPLY=() changes
> and it might be time to get rid of them.
>
> So this series supersedes that one.
COMPREPLY=() has nothing to do with it. My point is that there is no
"separate patch" that performs the alleged simplification made
possible by this patch, therefore that sentence should have been
removed from the log message for the resubmission.
^ permalink raw reply
* Re: [OT] How to get the discussion details via notes
From: Jeff King @ 2012-10-31 14:10 UTC (permalink / raw)
To: Peter Baumann; +Cc: Thomas Rast, Jonathan Nieder, git
In-Reply-To: <20121031095327.GB18557@m62s10.vlinux.de>
On Wed, Oct 31, 2012 at 10:53:27AM +0100, Peter Baumann wrote:
> > covers the basics (current behavior and intent of the change) in its
> > first two paragraphs and anyone wanting more detail can use
> >
> > GIT_NOTES_REF=refs/remotes/charon/notes/full \
> > git show --show-notes <commit>
> >
> > to find more details.
>
> I seem to miss something here, but I don't get it how the notes ref
> becomes magically filled with the details of this discussion.
Thomas Rast (aka charon) keeps a mapping of commits to the email threads
that led to them. You can fetch it from:
git://repo.or.cz/git/trast.git
(try the notes/full and notes/terse refs).
-Peff
^ permalink raw reply
* Re: [PATCH] parse_dirstat_params(): use string_list to split comma-separated string
From: Jeff King @ 2012-10-31 14:06 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <loom.20121030T193428-242@post.gmane.org>
On Tue, Oct 30, 2012 at 06:43:51PM +0000, Matt Kraai wrote:
> Michael Haggerty <mhagger <at> alum.mit.edu> writes:
> ...
> > -static int parse_dirstat_params(struct diff_options *options, const char ...
> > +static int parse_dirstat_params(struct diff_options *options, const char ...
> > struct strbuf *errmsg)
> > {
> > - const char *p = params;
> > - int p_len, ret = 0;
> > + char *params_copy = xstrdup(params_string);
> > + struct string_list params = STRING_LIST_INIT_NODUP;
> > + int ret = 0;
> > + int i;
> >
> > - while (*p) {
> > - p_len = strchrnul(p, ',') - p;
> > - if (!memcmp(p, "changes", p_len)) {
> > + 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?
-Peff
^ permalink raw reply
* Re: git-p4 clone @all error
From: Thomas Berg @ 2012-10-31 14:01 UTC (permalink / raw)
To: Arthur; +Cc: git
In-Reply-To: <1351593879401-7570219.post@n2.nabble.com>
Hi,
Sorry, forgot to reply-to-all, here is my response again:
On Tue, Oct 30, 2012 at 11:44 AM, Arthur <a.foulon@amesys.fr> wrote:
> The problem :
>
> Importing revision 7727 (100%)Traceback (most recent call last):
> File "/usr/bin/git-p4", line 3183, in <module>
> main()
> File "/usr/bin/git-p4", line 3177, in main
> if not cmd.run(args):
> File "/usr/bin/git-p4", line 3048, in run
> if not P4Sync.run(self, depotPaths):
> File "/usr/bin/git-p4", line 2911, in run
> self.importChanges(changes)
> File "/usr/bin/git-p4", line 2618, in importChanges
> self.initialParent)
> File "/usr/bin/git-p4", line 2198, in commit
> epoch = details["time"]
> KeyError: 'time'
>
Are you permanently converting a project, or are you planning to
continue submitting to perforce with git-p4?
I have seen similar bugs myself when using the --detect-branches
option. The branch detection in git-p4 is flaky anyway: it is limited
what it can handle, and it used to require correct perforce branch
specs at least, so I would recommend not using it unless you know what
it is doing under the hood.
Instead I would just clone a single branch at a time (drop the
--detect-branches) and work on that.
I do this even in the rare cases when I need more than one perforce
branch in the same git repo - there are other ways to achieve the same
thing.
- Thomas
^ permalink raw reply
* Re: change symlink
From: Jeff King @ 2012-10-31 13:44 UTC (permalink / raw)
To: shawn wilson; +Cc: Andreas Schwab, git
In-Reply-To: <20121031123057.GE30879@sigill.intra.peff.net>
On Wed, Oct 31, 2012 at 08:30:57AM -0400, Jeff King wrote:
> Something like this seems to fix it for me, but I am not sure if that
> would affect other callers.
> [...]
> + return !is_dir || !S_ISGITLINK(istate->cache[pos]->ce_mode);
That's completely wrong, of course. It should be:
return is_dir && !S_ISGITLINK(...);
(we found an index entry, so if it isn't a directory, then we know that
it is not untracked, and should return 0).
With that, we at least pass the test suite.
-Peff
^ permalink raw reply
* Re: git-p4 clone @all error
From: Arthur @ 2012-10-31 13:18 UTC (permalink / raw)
To: git
In-Reply-To: <1351593879401-7570219.post@n2.nabble.com>
up
--
View this message in context: http://git.661346.n2.nabble.com/git-p4-clone-all-error-tp7570219p7570343.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] git-push: update remote tags only with force
From: Chris Rorvick @ 2012-10-31 12:52 UTC (permalink / raw)
To: Drew Northup
Cc: git, Felipe Contreras, Jeff King, Michael Haggerty,
Angelo Borsotti, Philip Oakley, Johannes Sixt, Kacper Kornet
In-Reply-To: <CAM9Z-nk6YRtNXNHbp-ReXB78V0O01qng+zmWfzm7Yxz51x22Yw@mail.gmail.com>
On Wed, Oct 31, 2012 at 7:26 AM, Drew Northup <n1xim.email@gmail.com> wrote:
> On Wed, Oct 31, 2012 at 1:55 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>
>> but I wonder if it might be
>> possible to split it to ease the review.
>
> Agreed.
I'll look at splitting it up, probably not tonight though. :-)
> Also, do please CC ALL interested parties from the pre-patch
> discussion thread as well as those who previously maintained that
> chunk of code.
>
> [Attempted to reconstruct CC list of discussion]
Thanks for fixing that.
Chris
^ permalink raw reply
* Re: [PATCH] git-push: update remote tags only with force
From: Chris Rorvick @ 2012-10-31 12:36 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s2T9Rmfjd8r+2+eYh8JBPXEofm3cHuEkkY+R3cW6R6HxA@mail.gmail.com>
(oops, now my email was rejected)
On Wed, Oct 31, 2012 at 12:55 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Hi,
>
> (again because the mailing list rejected it) (Gmal switched interface
> and HTML is the default)
>
> On Wed, Oct 31, 2012 at 6:37 AM, Chris Rorvick <chris@rorvick.com> wrote:
>>
>> References are allowed to update from one commit-ish to another if the
>> former is a ancestor of the latter. This behavior is oriented to
>> branches which are expected to move with commits. Tag references are
>> expected to be static in a repository, though, thus an update to a
>> tag (lightweight and annotated) should be rejected unless the update is
>> forced.
>>
>> To enable this functionality, the following checks have been added to
>> set_ref_status_for_push() for updating refs (i.e, not new or deletion)
>> to restrict fast-forwarding in pushes:
>>
>> 1) The old and new references must be commits. If this fails,
>> it is not a valid update for a branch.
>>
>> 2) The reference name cannot start with "refs/tags/". This
>> catches lightweight tags which (usually) point to commits
>> and therefore would not be caught by (1).
>>
>> If either of these checks fails, then it is flagged (by default) with a
>> status indicating the update is being rejected due to the reference
>> already existing in the remote. This can be overridden by passing
>> --force to git push.
>>
>> The new status has the added benefit of being able to provide accurate
>> feedback as to why the ref update failed and what can be done.
>> Currently all ref update rejections are assumed to be for branches.
>
> Makes sense to me. I've believe I've been hit by this a couple of
> times when tags were updated, and a colleague did 'git push' and they
> went all back, or something like that. To handle that case properly
> probably more changes are needed, but this is a change in the right
> direction.
>
>> +test_expect_success 'push tag requires --force to update remote tag' '
>> + mk_test heads/master &&
>> + mk_child child1 &&
>> + mk_child child2 &&
>> + (
>> + cd child1 &&
>> + git tag lw_tag &&
>> + git tag -a -m "message 1" ann_tag &&
>> + git push ../child2 lw_tag &&
>> + git push ../child2 ann_tag &&
>> + >file1 &&
>> + git add file1 &&
>> + git commit -m "file1" &&
>> + git tag -f lw_tag &&
>> + git tag -f -a -m "message 2" ann_tag &&
>> + ! git push ../child2 lw_tag &&
>
> You probably should use test_must_fail.
Thanks, will fix.
> I don't see anything wrong with the patch, but I wonder if it might be
> possible to split it to ease the review.
I initially thought I'd split it into two: 1) to improve the feedback
and 2) to change the behavior. But (1) was shaping up to be similar
in size to the sum so I scrapped that idea. I will see what I can do.
Thanks,
Chris
^ permalink raw reply
* Re: change symlink
From: Jeff King @ 2012-10-31 12:30 UTC (permalink / raw)
To: shawn wilson; +Cc: Andreas Schwab, git
In-Reply-To: <20121031120505.GD30879@sigill.intra.peff.net>
On Wed, Oct 31, 2012 at 08:05:05AM -0400, Jeff King wrote:
> > however (what got me started wondering about this and a point i forgot
> > about) - t2/one/test doesn't show up under 'untracked files' in in
> > status that scenario. shouldn't it?
>
> Yes, I think that is a bug.
>
> My guess is that the presence of "test" in the index fools us from
> descending into the directory. And indeed, if you try "git status
> -uall", you will see the untracked file. So it is something with the
> directory traversal cutoff in the regular "-unormal" mode.
Something like this seems to fix it for me, but I am not sure if that
would affect other callers.
diff --git a/read-cache.c b/read-cache.c
index fda78bc..ae04a61 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1882,11 +1882,22 @@ int index_name_is_other(const struct index_state *istate, const char *name,
int namelen)
{
int pos;
- if (namelen && name[namelen - 1] == '/')
+ int is_dir = 0;
+
+ if (namelen && name[namelen - 1] == '/') {
namelen--;
+ is_dir = 1;
+ }
pos = index_name_pos(istate, name, namelen);
- if (0 <= pos)
- return 0; /* exact match */
+ if (0 <= pos) {
+ /* We got an exact match. However, if it is a directory,
+ * we still have to check that the entry in the index
+ * is a directory, too. If it isn't, then the old file went
+ * away, and now we may have untracked files inside the newly
+ * created directory.
+ */
+ return !is_dir || !S_ISGITLINK(istate->cache[pos]->ce_mode);
+ }
pos = -pos - 1;
if (pos < istate->cache_nr) {
struct cache_entry *ce = istate->cache[pos];
^ permalink raw reply related
* Re: [OT] How to get the discussion details via notes
From: Drew Northup @ 2012-10-31 12:29 UTC (permalink / raw)
To: Peter Baumann; +Cc: Jonathan Nieder, git
In-Reply-To: <20121031095327.GB18557@m62s10.vlinux.de>
On Wed, Oct 31, 2012 at 5:53 AM, Peter Baumann <waste.manager@gmx.de> wrote:
> Dropping the Cc list, as this is off topic
>
> On Tue, Oct 30, 2012 at 11:05:29PM -0700, Jonathan Nieder wrote:
>> Sverre Rabbelier wrote:
>>
>> > Thanks for the thorough explanation. Perhaps some of that could make
>> > it's way into the commit message?
>>
>> It's fine with me if it doesn't, since the original commit message
>> covers the basics (current behavior and intent of the change) in its
>> first two paragraphs and anyone wanting more detail can use
>>
>> GIT_NOTES_REF=refs/remotes/charon/notes/full \
>> git show --show-notes <commit>
>>
>> to find more details.
>
> I seem to miss something here, but I don't get it how the notes ref
> becomes magically filled with the details of this discussion.
>
> Care to explain?
If I have an email thread I'd like to store alongside a commit I'll
put that into a note, but I usually don't push that kind of thing out
to a remote repo.
Does that help?
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ 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