[PATCH] contrib: remote-helpers: add move warnings (v2.0)

[PATCH] contrib: remote-helpers: add move warnings (v2.0)

[Felipe Contreras]

The tools are now maintained out-of-tree, and they have a regression in
v2.0. It's better to start warning the users as soon as possible.

Can't possibly introduce regressions.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/git-remote-bzr | 3 +++
 contrib/remote-helpers/git-remote-hg  | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr
index 9abb58e..be4b9a3 100755
--- a/contrib/remote-helpers/git-remote-bzr
+++ b/contrib/remote-helpers/git-remote-bzr
@@ -43,6 +43,9 @@ import re
 import StringIO
 import atexit, shutil, hashlib, urlparse, subprocess
 
+sys.stderr.write('WARNING: git-remote-bzr is now maintained independently.\n')
+sys.stderr.write('WARNING: For more information visit https://github.com/felipec/git-remote-bzr\n')
+
 NAME_RE = re.compile('^([^<>]+)')
 AUTHOR_RE = re.compile('^([^<>]+?)? ?[<>]([^<>]*)(?:$|>)')
 EMAIL_RE = re.compile(r'([^ \t<>]+@[^ \t<>]+)')
diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 34cda02..989df66 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -25,6 +25,9 @@ import atexit
 import urlparse, hashlib
 import time as ptime
 
+sys.stderr.write('WARNING: git-remote-hg is now maintained independently.\n')
+sys.stderr.write('WARNING: For more information visit https://github.com/felipec/git-remote-hg\n')
+
 #
 # If you want to see Mercurial revisions as Git commit notes:
 # git config core.notesRef refs/notes/hg
-- 
1.9.2

Re: [PATCH] contrib: remote-helpers: add move warnings (v2.0)

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> The tools are now maintained out-of-tree, and they have a regression in
> v2.0.

You seem not to understand at all what a regression is.

My understanding is that versions of remote-hg shipped with all
versions of Git did not work with Hg 3.0, so not working with Hg 3.0
is a regression in v2.0 at all.  A recent report was about Hg 3.0
not working with 1.9.3, but I think you earlier said all versions of
Git does not work with Hg 3.0, and I can believe it.  That is hardly
a regression.

You could argue that Hg has a new regression to its external users
of its API when it went to 3.0.  We actually had a similar breakage
in 1.5.4, where it was reported late in the cycle after -rc0 [*1*]
that cgit that linked with our internal API libgit.a was broken by a
change on our side, which resulted in us fixing the breakage (even
though technically you may be able to say that it was cgit's fault
to link with libgit.a in the first place) with 18125644 (Move
sha1_file_to_archive into libgit, 2008-01-14) very late in the
cycle.  Calling that a regression in cgit would have been insane,
even if we did not patch our side up to accomodate it.

Stop this idiocy.


[References]

*1* http://thread.gmane.org/gmane.comp.version-control.git/70117/focus=71064

Re: [PATCH] contrib: remote-helpers: add move warnings (v2.0)

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > The tools are now maintained out-of-tree, and they have a regression in
> > v2.0.
> 
> You seem not to understand at all what a regression is.
> 
> My understanding is that versions of remote-hg shipped with all
> versions of Git did not work with Hg 3.0, so not working with Hg 3.0
> is a regression in v2.0 at all.

I explained to you multiple times already that is a different issue, but
it somehow doesn't get through your skull.

Let me try a different approach.

git-remote-bzr has a regression in Git v2.0.

Did you get the BAZAAR part? That's right, this is unrelated to
Mercurial v3.0 because it doesn't have anything to do with Mercurial.

*BOTH* git-remote-hg and git-remote-bzr have a regression in Git v2.0.

> A recent report was about Hg 3.0 not working with 1.9.3, but I think
> you earlier said all versions of Git does not work with Hg 3.0, and I
> can believe it.  That is hardly a regression.
> 
> You could argue that Hg has a new regression to its external users
> of its API when it went to 3.0.  We actually had a similar breakage
> in 1.5.4, where it was reported late in the cycle after -rc0 [*1*]
> that cgit that linked with our internal API libgit.a was broken by a
> change on our side, which resulted in us fixing the breakage (even
> though technically you may be able to say that it was cgit's fault
> to link with libgit.a in the first place) with 18125644 (Move
> sha1_file_to_archive into libgit, 2008-01-14) very late in the
> cycle.  Calling that a regression in cgit would have been insane,
> even if we did not patch our side up to accomodate it.
> 
> Stop this idiocy.

Sigh, you just don't seem to understand that you are thinking about a
different issue. I don't think there's any other way I can explain it to
you.

-- 
Felipe Contreras

Re: [PATCH] contrib: remote-helpers: add move warnings (v2.0)

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Sigh, you just don't seem to understand that you are thinking about a
> different issue. I don't think there's any other way I can explain it to
> you.

Perhaps pointing out which commit(s) to revert might be a good point
to start.

Re: [PATCH] contrib: remote-helpers: add move warnings (v2.0)

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Sigh, you just don't seem to understand that you are thinking about a
> > different issue. I don't think there's any other way I can explain it to
> > you.
> 
> Perhaps pointing out which commit(s) to revert might be a good point
> to start.

Oh, now you realize it might be nice to avoid this regression I warned
you about.

Why don't you continue schooling me about what constitutes a regression?
I'm such a slow learner.

I was going to do more than pointing to commits, I was going to provide
the fixes with test cases and a detailed explanation. But then you made
your decision.

This patch is what I'm suggesting you to do now. And I'll repeat what I
already told you.

Good luck with your tree.

-- 
Felipe Contreras

Re: [PATCH] contrib: remote-helpers: add move warnings (v2.0)

[Marius Storm-Olsen]

On 5/13/2014 5:47 PM, Felipe Contreras wrote:
> Junio C Hamano wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> Sigh, you just don't seem to understand that you are thinking
>>> about a different issue. I don't think there's any other way I
>>> can explain it to you.
>>
>> Perhaps pointing out which commit(s) to revert might be a good
>> point to start.
>
> Oh, now you realize it might be nice to avoid this regression I
> warned you about.
>
> Why don't you continue schooling me about what constitutes a
> regression? I'm such a slow learner.
>
> I was going to do more than pointing to commits, I was going to
> provide the fixes with test cases and a detailed explanation. But
> then you made your decision.

I believe the regression in question, mentioned at the bottom of this post
 
http://thread.gmane.org/gmane.comp.version-control.git/248263/focus=248269

     "Since you are not going to do so, I do not feel compelled to fix
      the synchronization crash regression that is present in v2.0.0-rc2
      and I already warned you about."

is referring to this patch
 
http://thread.gmane.org/gmane.comp.version-control.git/247546/focus=247549

but I admit, I'm getting a bit fuzzy around these discussions.

-- 
.marius

Re: [PATCH] contrib: remote-helpers: add move warnings (v2.0)

[Junio C Hamano]

Marius Storm-Olsen <mstormo@gmail.com> writes:

> On 5/13/2014 5:47 PM, Felipe Contreras wrote:
>> I was going to do more than pointing to commits, I was going to
>> provide the fixes with test cases and a detailed explanation. But
>> then you made your decision.
>
> I believe the regression in question, mentioned at the bottom of this post
>
> http://thread.gmane.org/gmane.comp.version-control.git/248263/focus=248269
>
>     "Since you are not going to do so, I do not feel compelled to fix
>      the synchronization crash regression that is present in v2.0.0-rc2
>      and I already warned you about."
>
> is referring to this patch
>
> http://thread.gmane.org/gmane.comp.version-control.git/247546/focus=247549
>
> but I admit, I'm getting a bit fuzzy around these discussions.

Thanks for trying to help.

The patch you pointed out however names 2594a79 as the culprit, but
it has been in 1.8.3 and upwards, so I am not sure what to say.  As
I do not recall seeing anything about "I already warned you about",
I fished the archive again, but the closest I found was this:

    http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248601

in which we heard "You won't be able to find the breakage." when I
hinted bisecting.  The only thing we saw was "I already said this
multiple times, but let me be clear once more: MASTER HAS A
REGRESSION (for all versions of Mercurial)." and I can believe if he
said that exact phrase multiple times, but I do not think he said
anything useful than "I broke 2.0 prereleases" anywhere---at least I
didn't find any "... with this commit in what way".

So at this point, I would have to say that the users of remote-hg is
taken hostage by its author.  One safe way forward at this point in
order to avoid regression would be to revert everything done by him
as suspicious, but that is a route that is too overcautious even for
me, and I am not willing to travel that road.

The "synch crash regression" points me more towards 3994e64d
(transport-helper: fix sync issue on crashes, 2014-04-12), though.
I would happily revert the merge d508e4a that pulled the topic into
v2.0.0-rc1.

-- >8 --
Subject: [PATCH] Revert "Merge branch 'fc/transport-helper-sync-error-fix'"

This reverts commit d508e4a8e2391ae2596403b6478d01cf3d5f928f,
reversing changes made to e42552135a2a396f37053a89f44952ea907870b2.

The author of the original topic says he broke the upcoming 2.0
release with something that relates to "synchronization crash
regression" while refusing to give further specifics, so this would
unfortunately be the safest option for the upcoming release.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/RelNotes/2.0.0.txt |  4 ---
 t/t5801-remote-helpers.sh        | 31 +++++------------
 transport-helper.c               | 73 ++++++++++++++++------------------------
 3 files changed, 37 insertions(+), 71 deletions(-)

diff --git a/Documentation/RelNotes/2.0.0.txt b/Documentation/RelNotes/2.0.0.txt
index 6e628d4..97f7df0 100644
--- a/Documentation/RelNotes/2.0.0.txt
+++ b/Documentation/RelNotes/2.0.0.txt
@@ -88,10 +88,6 @@ UI, Workflows & Features
  * "git grep" learned to behave in a way similar to native grep when
    "-h" (no header) and "-c" (count) options are given.
 
- * "git push" via transport-helper interface (e.g. remote-hg) has
-   been updated to allow forced ref updates in a way similar to the
-   natively supported transports.
-
  * The "simple" mode is the default for "git push".
 
  * "git add -u" and "git add -A", when run without any pathspec, is a
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index a00a660..25fd2e7 100755
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-remote-helpers.sh
@@ -212,30 +212,19 @@ test_expect_success 'push update refs failure' '
 	echo "update fail" >>file &&
 	git commit -a -m "update fail" &&
 	git rev-parse --verify testgit/origin/heads/update >expect &&
-	test_expect_code 1 env GIT_REMOTE_TESTGIT_FAILURE="non-fast forward" \
-		git push origin update &&
+	GIT_REMOTE_TESTGIT_PUSH_ERROR="non-fast forward" &&
+	export GIT_REMOTE_TESTGIT_PUSH_ERROR &&
+	test_expect_code 1 git push origin update &&
 	git rev-parse --verify testgit/origin/heads/update >actual &&
 	test_cmp expect actual
 	)
 '
 
-clean_mark () {
-	cut -f 2 -d ' ' "$1" |
-	git cat-file --batch-check |
-	grep commit |
-	sort >$(basename "$1")
-}
-
-cmp_marks () {
-	test_when_finished "rm -rf git.marks testgit.marks" &&
-	clean_mark ".git/testgit/$1/git.marks" &&
-	clean_mark ".git/testgit/$1/testgit.marks" &&
-	test_cmp git.marks testgit.marks
-}
-
 test_expect_success 'proper failure checks for fetching' '
-	(cd local &&
-	test_must_fail env GIT_REMOTE_TESTGIT_FAILURE=1 git fetch 2>error &&
+	(GIT_REMOTE_TESTGIT_FAILURE=1 &&
+	export GIT_REMOTE_TESTGIT_FAILURE &&
+	cd local &&
+	test_must_fail git fetch 2> error &&
 	cat error &&
 	grep -q "Error while running fast-import" error
 	)
@@ -243,11 +232,7 @@ test_expect_success 'proper failure checks for fetching' '
 
 test_expect_success 'proper failure checks for pushing' '
 	(cd local &&
-	git checkout -b crash master &&
-	echo crash >>file &&
-	git commit -a -m crash &&
-	test_must_fail env GIT_REMOTE_TESTGIT_FAILURE=1 git push --all &&
-	cmp_marks origin
+	test_must_fail env GIT_REMOTE_TESTGIT_FAILURE=1 git push --all
 	)
 '
 
diff --git a/transport-helper.c b/transport-helper.c
index b468e4f..86e1679 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -58,7 +58,7 @@ static int recvline_fh(FILE *helper, struct strbuf *buffer, const char *name)
 	if (strbuf_getline(buffer, helper, '\n') == EOF) {
 		if (debug)
 			fprintf(stderr, "Debug: Remote helper quit.\n");
-		return 1;
+		exit(128);
 	}
 
 	if (debug)
@@ -71,6 +71,12 @@ static int recvline(struct helper_data *helper, struct strbuf *buffer)
 	return recvline_fh(helper->out, buffer, helper->name);
 }
 
+static void xchgline(struct helper_data *helper, struct strbuf *buffer)
+{
+	sendline(helper, buffer);
+	recvline(helper, buffer);
+}
+
 static void write_constant(int fd, const char *str)
 {
 	if (debug)
@@ -157,8 +163,7 @@ static struct child_process *get_helper(struct transport *transport)
 	while (1) {
 		const char *capname;
 		int mandatory = 0;
-		if (recvline(data, &buf))
-			exit(128);
+		recvline(data, &buf);
 
 		if (!*buf.buf)
 			break;
@@ -195,9 +200,15 @@ static struct child_process *get_helper(struct transport *transport)
 		} else if (!strcmp(capname, "signed-tags")) {
 			data->signed_tags = 1;
 		} else if (starts_with(capname, "export-marks ")) {
-			data->export_marks = xstrdup(capname + strlen("export-marks "));
+			struct strbuf arg = STRBUF_INIT;
+			strbuf_addstr(&arg, "--export-marks=");
+			strbuf_addstr(&arg, capname + strlen("export-marks "));
+			data->export_marks = strbuf_detach(&arg, NULL);
 		} else if (starts_with(capname, "import-marks")) {
-			data->import_marks = xstrdup(capname + strlen("import-marks "));
+			struct strbuf arg = STRBUF_INIT;
+			strbuf_addstr(&arg, "--import-marks=");
+			strbuf_addstr(&arg, capname + strlen("import-marks "));
+			data->import_marks = strbuf_detach(&arg, NULL);
 		} else if (starts_with(capname, "no-private-update")) {
 			data->no_private_update = 1;
 		} else if (mandatory) {
@@ -296,9 +307,7 @@ static int set_helper_option(struct transport *transport,
 		quote_c_style(value, &buf, NULL, 0);
 	strbuf_addch(&buf, '\n');
 
-	sendline(data, &buf);
-	if (recvline(data, &buf))
-		exit(128);
+	xchgline(data, &buf);
 
 	if (!strcmp(buf.buf, "ok"))
 		ret = 0;
@@ -370,8 +379,7 @@ static int fetch_with_fetch(struct transport *transport,
 	sendline(data, &buf);
 
 	while (1) {
-		if (recvline(data, &buf))
-			exit(128);
+		recvline(data, &buf);
 
 		if (starts_with(buf.buf, "lock ")) {
 			const char *name = buf.buf + 5;
@@ -422,8 +430,6 @@ static int get_exporter(struct transport *transport,
 	struct helper_data *data = transport->data;
 	struct child_process *helper = get_helper(transport);
 	int argc = 0, i;
-	struct strbuf tmp = STRBUF_INIT;
-
 	memset(fastexport, 0, sizeof(*fastexport));
 
 	/* we need to duplicate helper->in because we want to use it after
@@ -434,14 +440,10 @@ static int get_exporter(struct transport *transport,
 	fastexport->argv[argc++] = "--use-done-feature";
 	fastexport->argv[argc++] = data->signed_tags ?
 		"--signed-tags=verbatim" : "--signed-tags=warn-strip";
-	if (data->export_marks) {
-		strbuf_addf(&tmp, "--export-marks=%s.tmp", data->export_marks);
-		fastexport->argv[argc++] = strbuf_detach(&tmp, NULL);
-	}
-	if (data->import_marks) {
-		strbuf_addf(&tmp, "--import-marks=%s", data->import_marks);
-		fastexport->argv[argc++] = strbuf_detach(&tmp, NULL);
-	}
+	if (data->export_marks)
+		fastexport->argv[argc++] = data->export_marks;
+	if (data->import_marks)
+		fastexport->argv[argc++] = data->import_marks;
 
 	for (i = 0; i < revlist_args->nr; i++)
 		fastexport->argv[argc++] = revlist_args->items[i].string;
@@ -561,9 +563,7 @@ static int process_connect_service(struct transport *transport,
 		goto exit;
 
 	sendline(data, &cmdbuf);
-	if (recvline_fh(input, &cmdbuf, name))
-		exit(128);
-
+	recvline_fh(input, &cmdbuf, name);
 	if (!strcmp(cmdbuf.buf, "")) {
 		data->no_disconnect_req = 1;
 		if (debug)
@@ -739,22 +739,16 @@ static int push_update_ref_status(struct strbuf *buf,
 	return !(status == REF_STATUS_OK);
 }
 
-static int push_update_refs_status(struct helper_data *data,
+static void push_update_refs_status(struct helper_data *data,
 				    struct ref *remote_refs,
 				    int flags)
 {
 	struct strbuf buf = STRBUF_INIT;
 	struct ref *ref = remote_refs;
-	int ret = 0;
-
 	for (;;) {
 		char *private;
 
-		if (recvline(data, &buf)) {
-			ret = 1;
-			break;
-		}
-
+		recvline(data, &buf);
 		if (!buf.len)
 			break;
 
@@ -772,7 +766,6 @@ static int push_update_refs_status(struct helper_data *data,
 		free(private);
 	}
 	strbuf_release(&buf);
-	return ret;
 }
 
 static int push_refs_with_push(struct transport *transport,
@@ -853,7 +846,8 @@ static int push_refs_with_push(struct transport *transport,
 	sendline(data, &buf);
 	strbuf_release(&buf);
 
-	return push_update_refs_status(data, remote_refs, flags);
+	push_update_refs_status(data, remote_refs, flags);
+	return 0;
 }
 
 static int push_refs_with_export(struct transport *transport,
@@ -911,15 +905,7 @@ static int push_refs_with_export(struct transport *transport,
 
 	if (finish_command(&exporter))
 		die("Error while running fast-export");
-	if (push_update_refs_status(data, remote_refs, flags))
-		return 1;
-
-	if (data->export_marks) {
-		strbuf_addf(&buf, "%s.tmp", data->export_marks);
-		rename(buf.buf, data->export_marks);
-		strbuf_release(&buf);
-	}
-
+	push_update_refs_status(data, remote_refs, flags);
 	return 0;
 }
 
@@ -988,8 +974,7 @@ static struct ref *get_refs_list(struct transport *transport, int for_push)
 
 	while (1) {
 		char *eov, *eon;
-		if (recvline(data, &buf))
-			exit(128);
+		recvline(data, &buf);
 
 		if (!*buf.buf)
 			break;
-- 
2.0.0-rc3-417-gef3bd82

Re: [PATCH] contrib: remote-helpers: add move warnings (v2.0)

[Felipe Contreras]

Junio C Hamano wrote:
> So at this point, I would have to say that the users of remote-hg is
> taken hostage by its author.

The users of remote-hg are being affected negatively *because* of your
decisions.

You have the power to help them by answering a simple question. Yet you
refuse to do that.

It's all on you.

-- 
Felipe Contreras

Re: [PATCH] contrib: remote-helpers: add move warnings (v2.0)

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Junio C Hamano wrote:
>> So at this point, I would have to say that the users of remote-hg is
>> taken hostage by its author.
>
> The users of remote-hg are being affected negatively *because* of your
> decisions.
>
> You have the power to help them by answering a simple question. Yet you
> refuse to do that.
>
> It's all on you.

That is exactly what I would call "taking users hostage".

I think I already answered that one question:

    I think after this insane amount of work I'm entitled to an answer for
    this *one* question.

    Instead you passive aggressively label me as a troll?

    This is really disquieting.

    Junio, do you honestly think I am a troll? Have at least the decency of
    telling it to me.

in $gmane/248853 with:

    You certainly are acting like one, aren't you?

Do you need more?

Re: [PATCH] contrib: remote-helpers: add move warnings (v2.0)

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Junio C Hamano wrote:
> >> So at this point, I would have to say that the users of remote-hg is
> >> taken hostage by its author.
> >
> > The users of remote-hg are being affected negatively *because* of your
> > decisions.
> >
> > You have the power to help them by answering a simple question. Yet you
> > refuse to do that.
> >
> > It's all on you.
> 
> That is exactly what I would call "taking users hostage".
> 
> I think I already answered that one question:

> in $gmane/248853 with:
> 
>     You certainly are acting like one, aren't you?
> 
> Do you need more?

You know full well this is not the question I asked you repeatedly. Stop
trying to spin the readers.

I asked you here:
http://article.gmane.org/gmane.comp.version-control.git/248683

And here:
http://article.gmane.org/gmane.comp.version-control.git/248348

And here:
http://article.gmane.org/gmane.comp.version-control.git/248368

I made it clear you were not answering the qustion here:
http://article.gmane.org/gmane.comp.version-control.git/248685

And here:
http://article.gmane.org/gmane.comp.version-control.git/248701

And here (apparently deleted mail):
1400013572-30232-1-git-send-email-felipe.contreras@gmail.com

And probably many other times.

And I will ask you once again.

Please answer this *one* question:

1) Please clarify the reason why you blocked the graduation of remote
   helpers. Please give the full rationale and do not point to other
   mails, or other peoples' explanations. If necessary attach such
   explanations to your full reasoning.

This is the *one* question you have refused to answer over and over.

-- 
Felipe Contreras

Re: [PATCH] contrib: remote-helpers: add move warnings (v2.0)

[Ronnie Sahlberg]

On Tue, May 13, 2014 at 3:22 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Junio C Hamano wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>> > The tools are now maintained out-of-tree, and they have a regression in
>> > v2.0.
>>
>> You seem not to understand at all what a regression is.
>>
>> My understanding is that versions of remote-hg shipped with all
>> versions of Git did not work with Hg 3.0, so not working with Hg 3.0
>> is a regression in v2.0 at all.
>
> I explained to you multiple times already that is a different issue, but
> it somehow doesn't get through your skull.


Could you please calm down and adjust your behavior.
This constant hostility and rudeness makes the mailing list very unpleasant.


>
> Let me try a different approach.
>
> git-remote-bzr has a regression in Git v2.0.
>
> Did you get the BAZAAR part? That's right, this is unrelated to
> Mercurial v3.0 because it doesn't have anything to do with Mercurial.
>
> *BOTH* git-remote-hg and git-remote-bzr have a regression in Git v2.0.
>
>> A recent report was about Hg 3.0 not working with 1.9.3, but I think
>> you earlier said all versions of Git does not work with Hg 3.0, and I
>> can believe it.  That is hardly a regression.
>>
>> You could argue that Hg has a new regression to its external users
>> of its API when it went to 3.0.  We actually had a similar breakage
>> in 1.5.4, where it was reported late in the cycle after -rc0 [*1*]
>> that cgit that linked with our internal API libgit.a was broken by a
>> change on our side, which resulted in us fixing the breakage (even
>> though technically you may be able to say that it was cgit's fault
>> to link with libgit.a in the first place) with 18125644 (Move
>> sha1_file_to_archive into libgit, 2008-01-14) very late in the
>> cycle.  Calling that a regression in cgit would have been insane,
>> even if we did not patch our side up to accomodate it.
>>
>> Stop this idiocy.
>
> Sigh, you just don't seem to understand that you are thinking about a
> different issue. I don't think there's any other way I can explain it to
> you.
>
> --
> Felipe Contreras
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] contrib: remote-helpers: add move warnings (v2.0)

[Felipe Contreras]

Ronnie Sahlberg wrote:
> Could you please calm down and adjust your behavior.  This constant
> hostility and rudeness makes the mailing list very unpleasant.

I explaind that to him multiple times. In the mail I replied to he is
once again assuming I'm a *insert-your-favorite-non-smart-adjective*,
and explaining to me what a regression is.

How many times must one repeat something before one is entitled so thay
something is not "getting through the skull" of another person? 5? 10?
20?

But fine, let's assume I do have to adjust my behavior. Maybe I should
have said "it doesn't register in your brain", or just "it fails to grab
your attention".

But if I have to adjust for saying that (which was true), what do you
say to Junio for saying this? (which was not)

> > Stop this idiocy.

I presume nothing, because Junio is a riskier target.

-- 
Felipe Contreras

Re: [PATCH] contrib: remote-helpers: add move warnings (v2.0)

[Ronnie Sahlberg]

On Tue, May 13, 2014 at 4:37 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Ronnie Sahlberg wrote:
>> Could you please calm down and adjust your behavior.  This constant
>> hostility and rudeness makes the mailing list very unpleasant.
>
> I explaind that to him multiple times. In the mail I replied to he is
> once again assuming I'm a *insert-your-favorite-non-smart-adjective*,
> and explaining to me what a regression is.
>
> How many times must one repeat something before one is entitled so thay
> something is not "getting through the skull" of another person? 5? 10?
> 20?
>
> But fine, let's assume I do have to adjust my behavior. Maybe I should
> have said "it doesn't register in your brain", or just "it fails to grab
> your attention".
>
> But if I have to adjust for saying that (which was true), what do you
> say to Junio for saying this? (which was not)

I know I shouldn't but I will respond anyway.

The problem is about you and your behaviour. Not Junio or anyone else.

Please adjust and stop your constant hostile, confrontational and
abusive behavior on this mailinglist.
Your behavior is not a winning strategy and will only result in
alienating you and impair your interactions with
the rest of the git community.


If anything, Junio have shown an amazing amount of patience and
restraint with you.
I would not have tolerated your kind of behavior in any project I am
maintainer for.


>
>> > Stop this idiocy.
>
> I presume nothing, because Junio is a riskier target.

Please follow Junio's advice. It will benefit both you as well as all
other participants in the community.

Re: [PATCH] contrib: remote-helpers: add move warnings (v2.0)

[Felipe Contreras]

Ronnie Sahlberg wrote:
> On Tue, May 13, 2014 at 4:37 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > But if I have to adjust for saying that (which was true), what do you
> > say to Junio for saying this? (which was not)
> 
> I know I shouldn't but I will respond anyway.
> 
> The problem is about you and your behaviour. Not Junio or anyone else.

Right. So when I say something moderately aggressive (but true), I'm the
problem, when Junio says something worst (and false), he is not.

Got it.

-- 
Felipe Contreras