[PATCH 0/4] remote-hg: more improvements

[PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

Here's a bunch of tests more, and a fixes for Mercurial v3.0.


Felipe Contreras (4):
  remote-hg: add more tests
  t: remote-hg: add file operation tests
  t: remote-hg: trivial cleanups and fixes
  remote-hg: add support for hg v3.0

 contrib/remote-helpers/git-remote-hg |   6 +-
 contrib/remote-helpers/test-hg.sh    | 240 ++++++++++++++++++++++++++++++++++-
 2 files changed, 238 insertions(+), 8 deletions(-)

-- 
1.9.2+fc1.20.g204a630

[PATCH 1/4] remote-hg: add more tests

[Felipe Contreras]

Inspired by the tests in gitifyhg.

One test is failing, but that's because of a limitation of
remote-helpers.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/test-hg.sh | 150 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 150 insertions(+)

diff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh
index 7d90056..33a434d 100755
--- a/contrib/remote-helpers/test-hg.sh
+++ b/contrib/remote-helpers/test-hg.sh
@@ -845,4 +845,154 @@ test_expect_success 'clone remote with generic null bookmark, then push to the b
 	)
 '
 
+test_expect_success 'notes' '
+	test_when_finished "rm -rf hgrepo gitrepo" &&
+
+	(
+	hg init hgrepo &&
+	cd hgrepo &&
+	echo one > content &&
+	hg add content &&
+	hg commit -m one &&
+	echo two > content &&
+	hg commit -m two
+	) &&
+
+	git clone "hg::hgrepo" gitrepo &&
+	hg -R hgrepo log --template "{node}\n\n" > expected &&
+	git --git-dir=gitrepo/.git log --pretty="tformat:%N" --notes=hg > actual &&
+	test_cmp expected actual
+'
+
+test_expect_failure 'push updates notes' '
+	test_when_finished "rm -rf hgrepo gitrepo" &&
+
+	(
+	hg init hgrepo &&
+	cd hgrepo &&
+	echo one > content &&
+	hg add content &&
+	hg commit -m one
+	) &&
+
+	git clone "hg::hgrepo" gitrepo &&
+
+	(
+	cd gitrepo &&
+	echo two > content &&
+	git commit -a -m two
+	git push
+	) &&
+
+	hg -R hgrepo log --template "{node}\n\n" > expected &&
+	git --git-dir=gitrepo/.git log --pretty="tformat:%N" --notes=hg > actual &&
+	test_cmp expected actual
+'
+
+test_expect_success 'pull tags' '
+	test_when_finished "rm -rf hgrepo gitrepo" &&
+
+	(
+	hg init hgrepo &&
+	cd hgrepo &&
+	echo one > content &&
+	hg add content &&
+	hg commit -m one
+	) &&
+
+	git clone "hg::hgrepo" gitrepo &&
+
+	(cd hgrepo && hg tag v1.0) &&
+	(cd gitrepo && git pull) &&
+
+	echo "v1.0" > expected &&
+	git --git-dir=gitrepo/.git tag > actual &&
+	test_cmp expected actual
+'
+
+test_expect_success 'push merged named branch' '
+	test_when_finished "rm -rf hgrepo gitrepo" &&
+
+	(
+	hg init hgrepo &&
+	cd hgrepo &&
+	echo one > content &&
+	hg add content &&
+	hg commit -m one &&
+	hg branch feature &&
+	echo two > content &&
+	hg commit -m two &&
+	hg update default &&
+	echo three > content &&
+	hg commit -m three
+	) &&
+
+	(
+	git clone "hg::hgrepo" gitrepo &&
+	cd gitrepo &&
+	git merge -m Merge -Xtheirs origin/branches/feature &&
+	git push
+	) &&
+
+	cat > expected <<-EOF
+	Merge
+	three
+	two
+	one
+	EOF
+	hg -R hgrepo log --template "{desc}\n" > actual &&
+	test_cmp expected actual
+'
+
+test_expect_success 'light tag sets author' '
+	test_when_finished "rm -rf hgrepo gitrepo" &&
+
+	(
+	hg init hgrepo &&
+	cd hgrepo &&
+	echo one > content &&
+	hg add content &&
+	hg commit -m one
+	) &&
+
+	(
+	git clone "hg::hgrepo" gitrepo &&
+	cd gitrepo &&
+	git tag v1.0 &&
+	git push --tags
+	) &&
+
+	echo "C O Mitter <committer@example.com>" > expected &&
+	hg -R hgrepo log --template "{author}\n" -r tip > actual &&
+	test_cmp expected actual
+'
+
+test_expect_success 'push tag different branch' '
+	test_when_finished "rm -rf hgrepo gitrepo" &&
+
+	(
+	hg init hgrepo &&
+	cd hgrepo &&
+	echo one > content &&
+	hg add content &&
+	hg commit -m one
+	hg branch feature &&
+	echo two > content &&
+	hg commit -m two
+	) &&
+
+	(
+	git clone "hg::hgrepo" gitrepo &&
+	cd gitrepo &&
+	git branch &&
+	git checkout branches/feature &&
+	git tag v1.0 &&
+	git push --tags
+	) &&
+
+	echo feature > expected &&
+	hg -R hgrepo log --template="{branch}\n" -r tip > actual &&
+	test_cmp expected actual
+'
+
 test_done
-- 
1.9.2+fc1.20.g204a630

[PATCH 2/4] t: remote-hg: add file operation tests

[Felipe Contreras]

Inspired by gitifyhg.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/test-hg.sh | 76 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 76 insertions(+)

diff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh
index 33a434d..df09966 100755
--- a/contrib/remote-helpers/test-hg.sh
+++ b/contrib/remote-helpers/test-hg.sh
@@ -53,6 +53,17 @@ check_bookmark () {
 	fi
 }
 
+check_files () {
+	git --git-dir=$1/.git ls-files > actual &&
+	if test $# -gt 1
+	then
+		printf "%s\n" "$2" > expected
+	else
+		> expected
+	fi &&
+	test_cmp expected actual
+}
+
 check_push () {
 	expected_ret=$1 ret=0 ref_ret=0
 
@@ -995,4 +1006,69 @@ test_expect_success 'push tag different branch' '
 	test_cmp expected actual
 '
 
+test_expect_success 'cloning a removed file works' '
+	test_when_finished "rm -rf hgrepo gitrepo" &&
+
+	(
+	hg init hgrepo &&
+	cd hgrepo &&
+
+	echo test > test_file &&
+	hg add test_file &&
+	hg commit -m add &&
+
+	hg rm test_file &&
+	hg commit -m remove
+	) &&
+
+	git clone "hg::hgrepo" gitrepo &&
+	check_files gitrepo
+'
+
+test_expect_success 'cloning a file replaced with a directory' '
+	test_when_finished "rm -rf hgrepo gitrepo" &&
+
+	(
+	hg init hgrepo &&
+	cd hgrepo &&
+
+	echo test > dir_or_file &&
+	hg add dir_or_file &&
+	hg commit -m add &&
+
+	hg rm dir_or_file &&
+	mkdir dir_or_file &&
+	echo test > dir_or_file/test_file &&
+	hg add dir_or_file/test_file &&
+	hg commit -m replase
+	) &&
+
+	git clone "hg::hgrepo" gitrepo &&
+	check_files gitrepo "dir_or_file/test_file"
+'
+
+test_expect_success 'clone replace directory with a file' '
+	test_when_finished "rm -rf hgrepo gitrepo" &&
+
+	(
+	hg init hgrepo &&
+	cd hgrepo &&
+
+	mkdir dir_or_file &&
+	echo test > dir_or_file/test_file &&
+	hg add dir_or_file/test_file &&
+	hg commit -m add &&
+
+	hg rm dir_or_file/test_file &&
+	echo test > dir_or_file &&
+	hg add dir_or_file &&
+	hg commit -m add &&
+
+	hg rm dir_or_file
+	) &&
+
+	git clone "hg::hgrepo" gitrepo &&
+	check_files gitrepo "dir_or_file"
+'
+
 test_done
-- 
1.9.2+fc1.20.g204a630

[PATCH 3/4] t: remote-hg: trivial cleanups and fixes

[Felipe Contreras]

There was a broken && chain, and cat is simpler than echo in a subshell.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/test-hg.sh | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh
index df09966..9b9468b 100755
--- a/contrib/remote-helpers/test-hg.sh
+++ b/contrib/remote-helpers/test-hg.sh
@@ -25,7 +25,7 @@ fi
 
 check () {
 	echo $3 >expected &&
-	git --git-dir=$1/.git log --format='%s' -1 $2 >actual
+	git --git-dir=$1/.git log --format='%s' -1 $2 >actual &&
 	test_cmp expected actual
 }
 
@@ -103,12 +103,12 @@ check_push () {
 }
 
 setup () {
-	(
-	echo "[ui]"
-	echo "username = H G Wells <wells@example.com>"
-	echo "[extensions]"
-	echo "mq ="
-	) >>"$HOME"/.hgrc &&
+	cat >> "$HOME"/.hgrc <<-EOF &&
+	[ui]
+	username = H G Wells <wells@example.com>
+	[extensions]
+	mq =
+	EOF
 
 	GIT_AUTHOR_DATE="2007-01-01 00:00:00 +0230" &&
 	GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE" &&
-- 
1.9.2+fc1.20.g204a630

[PATCH 4/4] remote-hg: add support for hg v3.0

[Felipe Contreras]

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/remote-helpers/git-remote-hg | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 34cda02..8b02803 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -13,6 +13,7 @@
 # "$GIT_DIR/hg/origin/clone/.hg/".
 
 from mercurial import hg, ui, bookmarks, context, encoding, node, error, extensions, discovery, util
+from mercurial import changegroup
 
 import re
 import sys
@@ -985,7 +986,10 @@ def push_unsafe(repo, remote, parsed_refs, p_revs):
     if not checkheads(repo, remote, p_revs):
         return None
 
-    cg = repo.getbundle('push', heads=list(p_revs), common=common)
+    if check_version(3, 0):
+        cg = changegroup.getbundle(repo, 'push', heads=list(p_revs), common=common)
+    else:
+        cg = repo.getbundle('push', heads=list(p_revs), common=common)
 
     unbundle = remote.capable('unbundle')
     if unbundle:
-- 
1.9.2+fc1.20.g204a630

Re: [PATCH 1/4] remote-hg: add more tests

[Eric Sunshine]

On Sat, May 3, 2014 at 10:16 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Inspired by the tests in gitifyhg.
>
> One test is failing, but that's because of a limitation of
> remote-helpers.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  contrib/remote-helpers/test-hg.sh | 150 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 150 insertions(+)
>
> diff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh
> index 7d90056..33a434d 100755
> --- a/contrib/remote-helpers/test-hg.sh
> +++ b/contrib/remote-helpers/test-hg.sh
> @@ -845,4 +845,154 @@ test_expect_success 'clone remote with generic null bookmark, then push to the b
>         )
>  '
>
> +test_expect_success 'notes' '
> +       test_when_finished "rm -rf hgrepo gitrepo" &&
> +
> +       (
> +       hg init hgrepo &&
> +       cd hgrepo &&
> +       echo one > content &&
> +       hg add content &&
> +       hg commit -m one &&
> +       echo two > content &&
> +       hg commit -m two
> +       ) &&
> +
> +       git clone "hg::hgrepo" gitrepo &&
> +       hg -R hgrepo log --template "{node}\n\n" > expected &&
> +       git --git-dir=gitrepo/.git log --pretty="tformat:%N" --notes=hg > actual &&
> +       test_cmp expected actual
> +'
> +
> +test_expect_failure 'push updates notes' '
> +       test_when_finished "rm -rf hgrepo gitrepo" &&
> +
> +       (
> +       hg init hgrepo &&
> +       cd hgrepo &&
> +       echo one > content &&
> +       hg add content &&
> +       hg commit -m one
> +       ) &&
> +
> +       git clone "hg::hgrepo" gitrepo &&
> +
> +       (
> +       cd gitrepo &&
> +       echo two > content &&
> +       git commit -a -m two
> +       git push
> +       ) &&
> +
> +       hg -R hgrepo log --template "{node}\n\n" > expected &&
> +       git --git-dir=gitrepo/.git log --pretty="tformat:%N" --notes=hg > actual &&
> +       test_cmp expected actual
> +'
> +
> +test_expect_success 'pull tags' '
> +       test_when_finished "rm -rf hgrepo gitrepo" &&
> +
> +       (
> +       hg init hgrepo &&
> +       cd hgrepo &&
> +       echo one > content &&
> +       hg add content &&
> +       hg commit -m one
> +       ) &&
> +
> +       git clone "hg::hgrepo" gitrepo &&
> +
> +       (cd hgrepo && hg tag v1.0) &&
> +       (cd gitrepo && git pull) &&
> +
> +       echo "v1.0" > expected &&
> +       git --git-dir=gitrepo/.git tag > actual &&
> +       test_cmp expected actual
> +'
> +
> +test_expect_success 'push merged named branch' '
> +       test_when_finished "rm -rf hgrepo gitrepo" &&
> +
> +       (
> +       hg init hgrepo &&
> +       cd hgrepo &&
> +       echo one > content &&
> +       hg add content &&
> +       hg commit -m one &&
> +       hg branch feature &&
> +       echo two > content &&
> +       hg commit -m two &&
> +       hg update default &&
> +       echo three > content &&
> +       hg commit -m three
> +       ) &&
> +
> +       (
> +       git clone "hg::hgrepo" gitrepo &&
> +       cd gitrepo &&
> +       git merge -m Merge -Xtheirs origin/branches/feature &&
> +       git push
> +       ) &&
> +
> +       cat > expected <<-EOF

Broken &&-chain.

> +       Merge
> +       three
> +       two
> +       one
> +       EOF
> +       hg -R hgrepo log --template "{desc}\n" > actual &&
> +       test_cmp expected actual
> +'
> +
> +test_expect_success 'light tag sets author' '
> +       test_when_finished "rm -rf hgrepo gitrepo" &&
> +
> +       (
> +       hg init hgrepo &&
> +       cd hgrepo &&
> +       echo one > content &&
> +       hg add content &&
> +       hg commit -m one
> +       ) &&
> +
> +       (
> +       git clone "hg::hgrepo" gitrepo &&
> +       cd gitrepo &&
> +       git tag v1.0 &&
> +       git push --tags
> +       ) &&
> +
> +       echo "C O Mitter <committer@example.com>" > expected &&
> +       hg -R hgrepo log --template "{author}\n" -r tip > actual &&
> +       test_cmp expected actual
> +'
> +
> +test_expect_success 'push tag different branch' '
> +       test_when_finished "rm -rf hgrepo gitrepo" &&
> +
> +       (
> +       hg init hgrepo &&
> +       cd hgrepo &&
> +       echo one > content &&
> +       hg add content &&
> +       hg commit -m one
> +       hg branch feature &&
> +       echo two > content &&
> +       hg commit -m two
> +       ) &&
> +
> +       (
> +       git clone "hg::hgrepo" gitrepo &&
> +       cd gitrepo &&
> +       git branch &&
> +       git checkout branches/feature &&
> +       git tag v1.0 &&
> +       git push --tags
> +       ) &&
> +
> +       echo feature > expected &&
> +       hg -R hgrepo log --template="{branch}\n" -r tip > actual &&
> +       test_cmp expected actual
> +'
> +
>  test_done
> --
> 1.9.2+fc1.20.g204a630
>
> --
> 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 0/4] remote-hg: more improvements

[Junio C Hamano]

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

> Here's a bunch of tests more, and a fixes for Mercurial v3.0.

I think the discussion with John Keeping hints that we shouldn't be
rushing fc/remote-helpers-hg-bzr-graduation and this does not appear
to assume the presense of that series, which is good in order to
make these fixes jump over them.

I'll queue this separately on a topic based on the tip of
yesterday's master for now.

One thing I couldn't read from the proposed log messages was if this
is meant to work with and tested with both v3.0 and pre-v3.0 Hg, or
this is to request others who run pre-v3.0 Hg to test these changes.

For example, I see

	from mercurial import changegroup
        if check_version(3, 0):
        	cg = changegroup.getbundle(...)
	else:
        	cg = repo.getbundle(...)

and offhand it was unclear if the unconditional import was a
mistake.

Thanks.

>
>
> Felipe Contreras (4):
>   remote-hg: add more tests
>   t: remote-hg: add file operation tests
>   t: remote-hg: trivial cleanups and fixes
>   remote-hg: add support for hg v3.0
>
>  contrib/remote-helpers/git-remote-hg |   6 +-
>  contrib/remote-helpers/test-hg.sh    | 240 ++++++++++++++++++++++++++++++++++-
>  2 files changed, 238 insertions(+), 8 deletions(-)

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Here's a bunch of tests more, and a fixes for Mercurial v3.0.
> 
> I think the discussion with John Keeping hints that we shouldn't be
> rushing fc/remote-helpers-hg-bzr-graduation

Really? Based on what reasoning? I have proven his reasoning to be
basically wrong.

> I'll queue this separately on a topic based on the tip of
> yesterday's master for now.
> 
> One thing I couldn't read from the proposed log messages was if this
> is meant to work with and tested with both v3.0 and pre-v3.0 Hg, or
> this is to request others who run pre-v3.0 Hg to test these changes.
> 
> For example, I see
> 
> 	from mercurial import changegroup
>         if check_version(3, 0):
>         	cg = changegroup.getbundle(...)
> 	else:
>         	cg = repo.getbundle(...)
> 
> and offhand it was unclear if the unconditional import was a
> mistake.

Of course it wasn't a mistake.

-- 
Felipe Contreras

Re: [PATCH 0/4] remote-hg: more improvements

[Junio C Hamano]

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

> Junio C Hamano wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> 
>> > Here's a bunch of tests more, and a fixes for Mercurial v3.0.
>> 
>> I think the discussion with John Keeping hints that we shouldn't be
>> rushing fc/remote-helpers-hg-bzr-graduation
>
> Really? Based on what reasoning? I have proven his reasoning to be
> basically wrong.

Perhaps s/proven/convinced myself only/; you didn't prove it to me
and I doubt you proved it to John.

>> For example, I see
>> 
>> 	from mercurial import changegroup
>>         if check_version(3, 0):
>>         	cg = changegroup.getbundle(...)
>> 	else:
>>         	cg = repo.getbundle(...)
>> 
>> and offhand it was unclear if the unconditional import was a
>> mistake.
>
> Of course it wasn't a mistake.

I doubt about the "Of course" part.  The first reaction after seeing
that the new "changegroup" is used only inside check_version(3,0)
and nowhere else was to wonder if that import is necessary (or even
safe) for the pre-v3.0 versions.

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> > Really? Based on what reasoning? I have proven his reasoning to be
> > basically wrong.
> 
> Perhaps s/proven/convinced myself only/; you didn't prove it to me
> and I doubt you proved it to John.

And you are still conveniently avoiding the question:

Based on what reasoning?

> > Of course it wasn't a mistake.
> 
> I doubt about the "Of course" part.  The first reaction after seeing
> that the new "changegroup" is used only inside check_version(3,0)
> and nowhere else was to wonder if that import is necessary (or even
> safe) for the pre-v3.0 versions.

I don't care about your first reaction. If that was only present in
newer versions, how do you think it would pass the testing on older
versions?

https://travis-ci.org/felipec/git

Normally I would explain the details of why this is the case, and send
the crash regresion fix for v2.0 with a clear explanation, but since you
are adamant in threating git-remote-hg/bzr as just another crappy
contrib script that doesn't even have tests like diff-highlight or
hg-to-git. Why would I care?

The fact that I'm the maintainer and I say it'ss good should be good
enough, and if the current version in "master" renders unusable the
existing Mercurial clones, hey, it's only in contrib, right?

-- 
Felipe Contreras

Re: [PATCH 0/4] remote-hg: more improvements

[Junio C Hamano]

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

> And you are still conveniently avoiding the question:
>
> Based on what reasoning?

Go re-read what was already said in the thread.  I still think
remote-hg and remote-bzr can and will flourish on their own merit,
and unbundling will be better for the end users for the reasons
stated there already.

Having said that, I've been thinking (not because of this thread,
but because I like imerge better and better these days) that there
should be a much better way to have a list of recommended third-party
plug-ins that enrich the Git ecosystem.  We have 

  https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools

(Jakub cc'ed as he often nudges those who announce their tools to
add an entry there) but honestly, git-scm.com is the first site the
end users who do not hack on Git would visit, and we probably should
have a catalog there (Scott and Peff cc'ed for that site).  One way
to help it may be to add a Documentation/gitthirdparty-tools.txt in
my tree that would automatically be pulled into git-scm.com site as
a part of the manual.  A richer ecosystem with tools outside my tree
would not materialize unless there is such a mechanism to advertise
the existence of them, and having to include a copy of each and
every third-party tools in my tree and keeping them relatively fresh
is not going to scale in the long run (Michael and Matthieu Cc'ed as
I saw exchanges on multimail in a near-by thread).

Such a file would probably cluster "plugins" into different
categories (post-receive hooks, remote-helpers, mergetools, etc.)
and limit the entry descriptions to a single paragraph of several
lines tops, with URL referring to the third-party maintainer's site
(e.g. a repository at GitHub).

>> > Of course it wasn't a mistake.
>> 
>> I doubt about the "Of course" part.  The first reaction after seeing
>> that the new "changegroup" is used only inside check_version(3,0)
>> and nowhere else was to wonder if that import is necessary (or even
>> safe) for the pre-v3.0 versions.
>
> I don't care about your first reaction. If that was only present in
> newer versions, how do you think it would pass the testing on older
> versions?
>
> https://travis-ci.org/felipec/git
>
> Normally I would explain the details of why this is the case, and send
> the crash regresion fix for v2.0 with a clear explanation,...

Without such an explanation in the log message, how would you expect
anybody to guess correctly?

Seriously, if you do not care about my first reaction, why do you
even want to live in my tree?

> The fact that I'm the maintainer and I say it'ss good should be good
> enough, and if the current version in "master" renders unusable the
> existing Mercurial clones, hey, it's only in contrib, right?

One potential merit I would see for keeping them in my tree is that
your change will see second opinions from others involved in the
project (including me), without giving a total rein based on the
sub-maintainership alone.  All the changes from sub-area maintainers
are vetted by at least two sets of eyeballs that way.

But after having to deal with you and seeing that you do not take
constructive criticism well, I doubt such a possibile merit will
ever materialize in the area where you alone work on.  Letting you
do whatever you want in your own tree may benefit the users of
remote-hg/remote-bzr better as the (bitter) second best option.

Re: [PATCH 0/4] remote-hg: more improvements

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Here's a bunch of tests more, and a fixes for Mercurial v3.0.
>
> I think the discussion with John Keeping hints that we shouldn't be
> rushing fc/remote-helpers-hg-bzr-graduation and this does not appear
> to assume the presense of that series, which is good in order to
> make these fixes jump over them.

When merged to a place somewhere early between the next and the pu
branches (aka "the jch branch", which is the version I usually use
myself), this seemed to break t5810, so I did today's integration
cycle one more time by excluding this topic and then instead queuing
it near the tip of the pu branch (read: today's 'pu' does not pass
the test suite for me).

There may be some other changes that this series depends on that I
may have missed that caused this breakage.  Can you take a look?

Thanks.

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > And you are still conveniently avoiding the question:
> >
> > Based on what reasoning?
> 
> Go re-read what was already said in the thread.

I already read it, and I already responded.

> I still think remote-hg and remote-bzr can and will flourish on their
> own merit,

Oh, you *think*. Well, what if you are wrong?

Or is that never a possibility? You are always right. Right?

> Having said that, I've been thinking (not because of this thread,
> but because I like imerge better and better these days) that there
> should be a much better way to have a list of recommended third-party
> plug-ins that enrich the Git ecosystem.

If and when such a mechanism exists, sure, it makes sense to move
functionality like git-p4 and git-remote-hg out of the core and contrib
areas.

But in the meantime what is ready for the core should be in the core.

> > Normally I would explain the details of why this is the case, and send
> > the crash regresion fix for v2.0 with a clear explanation,...
> 
> Without such an explanation in the log message, how would you expect
> anybody to guess correctly?

I don't. I told you it wasn't a mistake. If that's not enough for you,
that's *your* problem.

*If* git-remote-hg was to be part of the core, then sure, I would care
that you didn't understand why the patch is correct, and I would resend
immediately what a clear explanation.

But since it's only part of the contrib area which has such abundant
crap without documentation or tests. I do not care.

> Seriously, if you do not care about my first reaction, why do you
> even want to live in my tree?

As I already explained; I don't care about your reaction *because* you
don't want these tools to live in your tree.

> > The fact that I'm the maintainer and I say it'ss good should be good
> > enough, and if the current version in "master" renders unusable the
> > existing Mercurial clones, hey, it's only in contrib, right?
> 
> One potential merit I would see for keeping them in my tree is that
> your change will see second opinions from others involved in the
> project (including me), without giving a total rein based on the
> sub-maintainership alone.  All the changes from sub-area maintainers
> are vetted by at least two sets of eyeballs that way.
> 
> But after having to deal with you and seeing that you do not take
> constructive criticism well,

Oh, please. Up to the point where you decided unilaterally to move them
out of the core (they are alread in), all the constructive criticism to
git-remote-hg has been addressed properly.

I have spent an absurdely large amount of time working on git-remote-hg,
and the transport-helper to make sure everything works right. I even started
git-remote-bzr just to prove that the Python git_remote_helpers
framework was not needed, and eventually I made it work better than any
of the alternatives. I had to fight tooth-and-nail to prove that the
msysgit guys were wrong and my patch to handle UNINTERESTING refs
properly was right. Not to mention all the tests, the compatibility with
hg-git, and with gittifyhg, just to prove that my approach was superior
than the alternatives.

I addressed every issue reported constructively, every bug report was
fixed, every patch reviewed and usually improved by me. I made sure
users of older versions wouldn't be affected negatively when the marks
file was upgraded, and I even setup automatic tests for different
versions Bazaar and Mercurial that run every time I push to my
repository.

It is *way* beyond the quality of any other tool in 'contrib/' and even
some tools in the core, like 'git-request-pull' (which has known bugs),
and probably even 'git-pt'.

Even you agreed it would be beneficial to move them out of contrib; it
would benefit *everyone*. And there was no reason not to.

And then some random guy comes with a few bad arguments, and you change
your mind.

That's f*cking double standards. Pure and simple.

If git-remote-hg belongs out-of-tree, so does git-svn and git-p4. If
git-remote-hg belongs in the contrib area, so does git-svn, and git-p4.

After all this insane amout of work you are acting as if git-remote-hg
wasn't ready to move to the core, because I didn't explain *one* commit
properly to you (which happened after this bullshit).

If these helpers are not going to move forward why would I care? Give me
why one good reason why I should give a flying f*ck about the state of
remote-helpers in *your* tree after this (and BTW as things stand now,
it's not good).

It was *your* users who urged me to send my patches upstream.

> I doubt such a possibile merit will ever materialize in the area where
> you alone work on.

And there it is. Ad hominem rationale.

> Letting you do whatever you want in your own tree may benefit the
> users of remote-hg/remote-bzr better as the (bitter) second best
> option.

If and when there is a mechanism promoting out-of-tree tools, that
might be the case.

In the meantime virtually every tool that is worth using lives in
git.git and is distributed by default. Everything else is sub-par in the
minds of Git users.

One tool being dropped from the tree while other tools remain there is
not going to send a positive message to its users.

If you are so confident git-remote-hg would "flourish" out-of-tree, drop
git-p4 and git-svn, see what is the reaction.

-- 
Felipe Contreras

Re: [PATCH 0/4] remote-hg: more improvements

[James Denholm]

Felipe, I would ask, suggest, beg, implore you to calm down. It's
generally not a good plan to alienate the maintainer of a project,
regardless of the correctness or incorrectness of one's arguments, but I
fear that's only what you will achieve at the moment.

--
Regards,
James Denholm.

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Felipe Contreras <felipe.contreras@gmail.com> writes:
> >
> >> Here's a bunch of tests more, and a fixes for Mercurial v3.0.
> >
> > I think the discussion with John Keeping hints that we shouldn't be
> > rushing fc/remote-helpers-hg-bzr-graduation and this does not appear
> > to assume the presense of that series, which is good in order to
> > make these fixes jump over them.
> 
> When merged to a place somewhere early between the next and the pu
> branches (aka "the jch branch", which is the version I usually use
> myself), this seemed to break t5810, so I did today's integration
> cycle one more time by excluding this topic and then instead queuing
> it near the tip of the pu branch (read: today's 'pu' does not pass
> the test suite for me).
> 
> There may be some other changes that this series depends on that I
> may have missed that caused this breakage.  Can you take a look?

I'm such a bad maintainer and I don't take constructive criticism well
why would you expect me to take a look?

As usual, I did more than take a look and I went ahead to manually test
with multiple versions of Mercurial. The problem appears with hg < 2.6.

Here's the fix:

--- a/git-remote-hg.py
+++ b/git-remote-hg.py
@@ -905,7 +905,7 @@ def write_tag(repo, tag, node, msg, author):
         try:
             fctx = tip.filectx(f)
             data = fctx.data()
-        except error.ManifestLookupError:
+        except error.LookupError:
             data = ""
         content = data + "%s %s\n" % (node, tag)
         return context.memfilectx(f, content, False, False, None)

-- 
Felipe Contreras

Re: [PATCH 0/4] remote-hg: more improvements

[Junio C Hamano]

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

>> There may be some other changes that this series depends on that I
>> may have missed that caused this breakage.  Can you take a look?
>
> I'm such a bad maintainer and I don't take constructive criticism well
> why would you expect me to take a look?

Because this was not about maintainership, but was a simple and
straight-forward breakage report [*1*].  There was no criticism
involved, constructive or otherwise.

In other words, I knew that you are capable enough to track down a
bug in the code you wrote recently that made it violate the
expectation you defined in your own tests.  There was no room for
differences of opinions to come into play, as it was just between
you and your own code.

Why would I expect otherwise?

Do you want to make it a separate follow-up patch with a log message
that explains why it now uses LookupError (not ManifestLookupError),
or do you want to reroll the original by squashing it?  I am guessing
that the reason is because in older versions they used LookupError
but in recent versions ManifestLookupError which is a subclass is
thrown instead, and catching the former would cover both cases, so
if I were to queue it as a separate [PATCH 5/4] fixup, that is how
I would explain that change.

[Footnote]

*1* .... and a very bad one at that, missing any useful details; I
apologize and blame lack of time for its lousiness.

Thanks for working with very little useful information and fixing.

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

Junio C Hamano wrote:
> In other words, I knew that you are capable enough to track down a
> bug in the code you wrote recently that made it violate the
> expectation you defined in your own tests.

Wrong. The code in question was not recent, it was introdued in 1.8.3,
more than one year ago.

And wrong, it didn't violate the expectation of my own tests.

The code was simply not exercised in the tests.

> There was no room for differences of opinions to come into play, as it
> was just between you and your own code.
> 
> Why would I expect otherwise?

Because most people take attacks on their code as personal attacks, and
they don't fix bugs in their code if they don't like the person
reporting it.

But you know I don't take attacks on my code and ideas personally, which
is more that can be said of most people on the list.

> Do you want to make it a separate follow-up patch with a log message
> that explains why it now uses LookupError (not ManifestLookupError),
> or do you want to reroll the original by squashing it?

I don't want to do anything for a "contrib" tool.

It's already broken in v2.0 anyway.

-- 
Felipe Contreras

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

James Denholm wrote:
> Felipe, I would ask, suggest, beg, implore you to calm down.

I am calmed down. I waited a day before replying to make sure of that.

> It's generally not a good plan to alienate the maintainer of a
> project, regardless of the correctness or incorrectness of one's
> arguments, but I fear that's only what you will achieve at the moment.

He has already alienated me. In fact he asked me before to leave the
mailing list. And I did for a while.

However, at some level he knows my patches are beneficial to the
project, so he is applying them again.

Either way it doesn't matter if I'm calmed down or not, abrassive or
civil, this ad hominmen double standards bullshit is going to continue.

See what was his reply to my mail? *Nothing*.

What was his reply when I argued if he even admitted he could
potentially be wrong, and if so would essentially trash a project I've
worked very hard for? *Nothing*.

What was his reply when I argued that git-remote-hg has more quality
than all the tools in contrib, even some in the core and therefore
doesn't belong there? *Nothing*.

What was his reply when I said double standards were applied for
git-remote-hg. *Nothing*.

How about when I argued there was no mechanism for out-of-tree tools to
be properly maintained and promoted, and moving tools outside of the
tree shouldn't be done before that happens? *Nothing*.

What did he say when I suggested to move out git-p4 and git-svn, if he
is so sure important tools can "flourish" out-of-tree? *Nothing*.

The truth is that it doesn't matter how I present my arguments, calmly
or otherwise. He is *never* going to accept he was wrong, especially not
when that would mean I was right.

Don't expect any more git-remote-hg patches from me. If Junio thinks
it's just another crappy contrib tool, then I'll threat it as one.

And unfortunately Junio would rather let an important part of Git die a
slow death rather than admit he was wrong. Just watch him ignore the
problem.

-- 
Felipe Contreras

Re: [PATCH 0/4] remote-hg: more improvements

[Junio C Hamano]

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

> Junio C Hamano wrote:
>> In other words, I knew that you are capable enough to track down a
>> bug in the code you wrote recently that made it violate the
>> expectation you defined in your own tests.
>
> Wrong. The code in question was not recent, it was introdued in 1.8.3,
> more than one year ago.
>
> And wrong, it didn't violate the expectation of my own tests.
>
> The code was simply not exercised in the tests.
>
>> There was no room for differences of opinions to come into play, as it
>> was just between you and your own code.

OK, I misread the blame output---sorry about that.

But that does not change the fact that your tests caught a bug in
your own code, and the issue was solely between you and your own
code without involving criticism from anybody, does it?

Unless you count a barf from a rather old version of Mercurial as a
criticism, that is.

>> Why would I expect otherwise?
>>
> Because most people take attacks on their code as personal attacks, and
> they don't fix bugs in their code if they don't like the person
> reporting it.
>
> But you know I don't take attacks on my code and ideas personally, which
> is more that can be said of most people on the list.

Just to make sure new people who may be watching with popcorns in
their hand from sidelines do not get a wrong impression, I do not
share your "most people take attacks ..." observation.

In reviews I have seen over the years around here (and also reviews
at $DAYJOB), I rarely saw such a reaction by the person whose change
is reviewed.  I view this list as very cooperative and productive
environment most of the time.

In any case, there was not even any attack---it was merely your code
not passing your own test on a platform you did not have access to,
which is not something to be upset about.

> I don't want to do anything for a "contrib" tool.
>
> It's already broken in v2.0 anyway.

Yes, this is not even an old regression.  If you no longer want to
have it in contrib/, I can drop it in future releases (but not in
v2.0), so that people can find the latest and greatest directly from
you.  Otherwise, queuing a fix on 'pu' and then to 'next' in
preparation for an early graduation for the release after v2.0 (and
as a fix, it may want to go to older maintenance releases) is also
fine by me.

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

Junio C Hamano wrote:

> > I don't want to do anything for a "contrib" tool.
> >
> > It's already broken in v2.0 anyway.
> 
> Yes, this is not even an old regression.

Yes it is. It has nothing to do with with Mercurial v3.0, that's a
separate issue. We've been doing a workaround since v1.8.3, and that
workaround will break things in v2.0.

I already said this multiple times, but let me be clear once more:

MASTER HAS A REGRESSION (for all versions of Mercurial).

> If you no longer want to have it in contrib/, I can drop it in future
> releases (but not in v2.0), so that people can find the latest and
> greatest directly from you.  Otherwise, queuing a fix on 'pu' and then
> to 'next' in preparation for an early graduation for the release after
> v2.0 (and as a fix, it may want to go to older maintenance releases)
> is also fine by me.

Are you saying that the graduation plan is going to continue and they
are going to move out of contrib and be distributed by default?

If that's the case I'll resume the fixes because the current sitution is
not good.

-- 
Felipe Contreras

Re: [PATCH 0/4] remote-hg: more improvements

[Junio C Hamano]

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

> I already said this multiple times, but let me be clear once more:
>
> MASTER HAS A REGRESSION (for all versions of Mercurial).

As you said, that is not a regression, isn't it?  It is an old
breakage that existed even before 1.9 (was it 1.8.3 or something?)

>> If you no longer want to have it in contrib/, I can drop it in future
>> releases (but not in v2.0), so that people can find the latest and
>> greatest directly from you.  Otherwise, queuing a fix on 'pu' and then
>> to 'next' in preparation for an early graduation for the release after
>> v2.0 (and as a fix, it may want to go to older maintenance releases)
>> is also fine by me.
>
> Are you saying that the graduation plan is going to continue and they
> are going to move out of contrib and be distributed by default?

I do not think that is going to happen.  As we discussed already, I
do see merit in unbundling it from my tree.  I can keep it in contrib/
as that is a slight benefit for you (i.e. you can be lock-step with
Git) but as long as you live in my tree, you need to follow the same
release schedule as the other contributors, which may be detrimental
to your users, compared to a case where it is unbundled.

I do not see a strong reason to move it out of contrib, either.

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > I already said this multiple times, but let me be clear once more:
> >
> > MASTER HAS A REGRESSION (for all versions of Mercurial).
> 
> As you said, that is not a regression, isn't it?  It is an old
> breakage that existed even before 1.9 (was it 1.8.3 or something?)

No. It does't happen in 1.9, it will happen in 2.0.

That's a REGRESSION.

> >> If you no longer want to have it in contrib/, I can drop it in future
> >> releases (but not in v2.0), so that people can find the latest and
> >> greatest directly from you.  Otherwise, queuing a fix on 'pu' and then
> >> to 'next' in preparation for an early graduation for the release after
> >> v2.0 (and as a fix, it may want to go to older maintenance releases)
> >> is also fine by me.
> >
> > Are you saying that the graduation plan is going to continue and they
> > are going to move out of contrib and be distributed by default?
> 
> I do not think that is going to happen.

Then I don't understand what you mean by "graduation".

> As we discussed already, I do see merit in unbundling it from my tree.

You are blind. Move git-p4 and git-svn out of your tree.

You know what will happen.

> I can keep it in contrib/ as that is a slight benefit for you

What is the benefit of being in contrib/? Even you yourself argued that
there is not much point of 'contrib/' nowadays[1]. The only reason we
might want something in contrib/ is so that it has a chance to mature
before becoming part of the core.

> (i.e. you can be lock-step with Git) but as long as you live in my
> tree, you need to follow the same release schedule as the other
> contributors, which may be detrimental to your users, compared to a
> case where it is unbundled.

It's much more beneficial to *our* users if these tools are distributed
by default.

> I do not see a strong reason to move it out of contrib, either.

Really? So why did you say this?[2]

> > Either way, I think if things go well, remote-hg will prove it's
> > worth and move out of contrib and into git's core.
> 
> That was what you promised when we started carrying it in contrib/; I
> am still hoping to see it happen when it matures.

Jeff said the same thing when he was acting as maintainer[3], and you
didn't correct him:

> I would one day like to have it as part of the main distribution, too,
> but it would be nice to prove its worth in the field for a while
> first.

All this time I've been operating under the impression that once
git-remote-hg proved itself, it would graduate out of contrib.

So basically you tricked me, and I wasted insane amounts of time chasing
a target that was impossible to reach.

Fuck this.

[1] http://article.gmane.org/gmane.comp.version-control.git/220178
[2] http://article.gmane.org/gmane.comp.version-control.git/220277
[3] http://article.gmane.org/gmane.comp.version-control.git/208648

-- 
Felipe Contreras

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

Felipe Contreras wrote:
> Junio C Hamano wrote:

> > I do not see a strong reason to move it out of contrib, either.
> 
> Really? So why did you say this?[2]
> 
> > > Either way, I think if things go well, remote-hg will prove it's
> > > worth and move out of contrib and into git's core.
> > 
> > That was what you promised when we started carrying it in contrib/; I
> > am still hoping to see it happen when it matures.
> 
> Jeff said the same thing when he was acting as maintainer[3], and you
> didn't correct him:
> 
> > I would one day like to have it as part of the main distribution, too,
> > but it would be nice to prove its worth in the field for a while
> > first.
> 
> All this time I've been operating under the impression that once
> git-remote-hg proved itself, it would graduate out of contrib.
> 
> So basically you tricked me, and I wasted insane amounts of time chasing
> a target that was impossible to reach.

Even contrib/README says so:

  I expect that things that start their life in the contrib/ area
  to graduate out of contrib/ once they mature, either by becoming
  projects on their own, or moving to the toplevel directory.  On
  the other hand, I expect I'll be proposing removal of disused
  and inactive ones from time to time.

-- 
Felipe Contreras

Re: [PATCH 0/4] remote-hg: more improvements

[Junio C Hamano]

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

> Junio C Hamano wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> 
>> > I already said this multiple times, but let me be clear once more:
>> >
>> > MASTER HAS A REGRESSION (for all versions of Mercurial).
>> 
>> As you said, that is not a regression, isn't it?  It is an old
>> breakage that existed even before 1.9 (was it 1.8.3 or something?)
>
> No. It does't happen in 1.9, it will happen in 2.0.
>
> That's a REGRESSION.

You earlier said in our exchange:

    > Wrong. The code in question was not recent, it was introdued in 1.8.3,
    > more than one year ago.

and "git blame -L870,880 contrib/remote-helpers/git-remote-hg" does
show that 68d4f4f3 (remote-hg: custom method to write tags,
2013-04-22) is the culplit that has introduced ManifestLookupError.

And it is in since 1.8.3.  How does it break 2.0 and without
breaking 1.9?  The dormant and otherwise unused code got its first
caller, or something?

If this were a core part of the system the only sensible thing we
can do at this point is to revert at this late stage of the cycle,
but I do not think I have time to bisect and find that culprit, as
today is when -rc3 has been scheduled to happen.

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Junio C Hamano wrote:
> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >> 
> >> > I already said this multiple times, but let me be clear once more:
> >> >
> >> > MASTER HAS A REGRESSION (for all versions of Mercurial).
> >> 
> >> As you said, that is not a regression, isn't it?  It is an old
> >> breakage that existed even before 1.9 (was it 1.8.3 or something?)
> >
> > No. It does't happen in 1.9, it will happen in 2.0.
> >
> > That's a REGRESSION.
> 
> You earlier said in our exchange:
> 
>     > Wrong. The code in question was not recent, it was introdued in 1.8.3,
>     > more than one year ago.
> 
> and "git blame -L870,880 contrib/remote-helpers/git-remote-hg" does
> show that 68d4f4f3 (remote-hg: custom method to write tags,
> 2013-04-22) is the culplit that has introduced ManifestLookupError.

That is not a regression. It's not the issue I'm talking about.

> And it is in since 1.8.3.

That is a coincidence.

> How does it break 2.0 and without breaking 1.9?

I said it breaks ALL VERSIONS. You are looking at two issues that are
unrelated to the one I'm talking about.

> If this were a core part of the system the only sensible thing we
> can do at this point is to revert at this late stage of the cycle,
> but I do not think I have time to bisect and find that culprit, as
> today is when -rc3 has been scheduled to happen.

You won't be able to find the breakage.

Good luck with your tree.

-- 
Felipe Contreras

Re: [PATCH 0/4] remote-hg: more improvements

[Philippe Vaucher]

> I addressed every issue reported constructively, every bug report was
> fixed, every patch reviewed and usually improved by me. I made sure
> users of older versions wouldn't be affected negatively when the marks
> file was upgraded, and I even setup automatic tests for different
> versions Bazaar and Mercurial that run every time I push to my
> repository.
>
> It is *way* beyond the quality of any other tool in 'contrib/' and even
> some tools in the core, like 'git-request-pull' (which has known bugs),
> and probably even 'git-pt'.

Junio, can you comment on this? I understand this probably doesn't
really affect the issue at hand, but it'd help clarify if it's ever
possible to move out of contrib/ nowadays.


> If git-remote-hg belongs out-of-tree, so does git-svn and git-p4. If
> git-remote-hg belongs in the contrib area, so does git-svn, and git-p4.

Here too, can you clarify a bit about what should be out of tree and
what should be in contrib? I understand that not all rules are set in
stone and that there is an historical baggage for which applying all
rules is probably more trouble than it's worth, but again it's nice to
clarify for future users. Also it'd probably be worth commenting on
unwritten rules about human factors (easyness of communication,
response to criticisim, ability to make concessions, etc).

Philippe

Re: [PATCH 0/4] remote-hg: more improvements

[Philippe Vaucher]

Nevermind, it'd be more efficient to cover this in the other main
thread started by Felipe. You can answer my questions there instead as
it'll likely benefit a wider audience.

Philippe

Re: [PATCH 0/4] remote-hg: more improvements

[Junio C Hamano]

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

>> It is *way* beyond the quality of any other tool in 'contrib/' and even
>> some tools in the core, like 'git-request-pull' (which has known bugs),
>> and probably even 'git-pt'.
>
> Junio, can you comment on this? I understand this probably doesn't
> really affect the issue at hand, but it'd help clarify if it's ever
> possible to move out of contrib/ nowadays.

I was originally led to believe that its code quality was good
enough, and that was why I merged the bottom three patches of the
series even down to 'next' in the first place.  But after seeing the
"Of course" response that led to [*1*], which made me recall many
patch-review interactions with him, I have started to have doubts.

The code quality of Git that many projects have come to trust their
code with is much more than just "the code at each moment keeps
working for the users as long as the original author is around".
The maintainer of a port to the platform X may lose access to the
platform after switching jobs, the maintainer of a bridge to the
foreign system Y may stop needing to talk to the foreign system
after completing the switch to Git.  Anybody can be hit by a bus,
get sick, or simply lose interest in his past creations.

By reading "git log contrib/remote-helpers" and comparing it with
the logs for the rest of the system, you would realize that the
former would not lead to a quality discussion similar to the one
that led to [*2*], which was only possible because the change was
adequately described to allow anybody to understand the original
issue the change was meant to solve.  The commit that made the
original change made it easy to ask a critical question: "You are
improving B but at the same time breaking A.  Can we do better to
help both A and B?"  And it allowed us to move forward without
having to rob Peter to pay Paul.

Granted, these contrib/ patches were applied with the understanding
that contrib/ stuff can be substandard, because having anything is
often better than having nothing, and you cannot go back in time to
update the history to make these commits more useful to others who
will come later.  But I would be lying if I said that I would expect
that things will suddenly improve and that the codebase will be
maintained for the long haul in a healthy way the minute we move it
out of contrib/ to the core.  Especially after seeing [*1*], which
is just one of the examples that illustrate that there clearly is no
will to explain the changes to help others who come later to help
maintaining the code.  "I'll take good care of the codebase", "I've
spend the time to make it better", "Me, me, me", is not what the
open source process is about.


[References]

*1* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341
*2* http://thread.gmane.org/gmane.comp.version-control.git/248075/focus=248204

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

Junio C Hamano wrote:
> Philippe Vaucher <philippe.vaucher@gmail.com> writes:
> 
> >> It is *way* beyond the quality of any other tool in 'contrib/' and even
> >> some tools in the core, like 'git-request-pull' (which has known bugs),
> >> and probably even 'git-pt'.
> >
> > Junio, can you comment on this? I understand this probably doesn't
> > really affect the issue at hand, but it'd help clarify if it's ever
> > possible to move out of contrib/ nowadays.
> 
> I was originally led to believe that its code quality was good
> enough, and that was why I merged the bottom three patches of the
> series even down to 'next' in the first place.  But after seeing the
> "Of course" response that led to [*1*], which made me recall many
> patch-review interactions with him, I have started to have doubts.

This is bullshit, and a wrong direction fallacy.

Event #1:
Junio rejects the graduation
http://article.gmane.org/gmane.comp.version-control.git/248263

Event #2:
I give up improving remote helpers in git.git
http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341

Junio is trying to make you believe that his decision (#1) was caused by
something I did (#2). Don't fall into that trap, #2 happened *AFTER* #1,
it can't possibly be the cause.

> But I would be lying if I said that I would expect
> that things will suddenly improve and that the codebase will be
> maintained for the long haul in a healthy way the minute we move it
> out of contrib/ to the core.  Especially after seeing [*1*]

[1] happened *AFTER* you made that stupid decision.

Don't make it look as if your decision was caused by [1], *YOU* caused
[1].

If you want to show that the quality of the commit messages or the code
caused that decision, show an issue in that respect that happened
*BEFORE* your decision.

It is very clear what is happening. Junio made a wrong decision based a
non-issue, then it became abudantly clear that there was no basis for
such decision, this why he never clarified the reasoning behind. Then,
*AFTER* I reacted to his decision he grabbed that opportunity to say
"no, look, this _new_ thing Felipe is doing is the reason". Nice try.

If the behavior in [1] is the reason, the solution is easy; I'll revert
back to my old behavior where I explained everything in detail, and
updated the commit messages if something wasn't clear.

I would:

 1. Make sure the regression is fixed Git v2.0
 2. Send a clarified patch for the hg 3.0 compatibility
 3. Look for other important patches that might be missing and provide
    all the details why they are important
 4. Rebase and clean the rest of the patches to make sure nothing is
    missing

This is what I was going to do anyway *BEFORE* you made that decision.
And this commitment to quality is what I've been doing since day one.
*YOU* changed that by throwing away all my hard work.

If the issue was truly the behavior in [1], the outline above should get
rid of the (fake) problem you mention.

We make a compromise, you ignore this temporary bump (that *you*
caused), and I go "back" to high quality standards (which I was already
doing anyway before). The graduation process continues, and *IF* another
instance like [1] comes (it won't), then the graduation process is
canceled.

Ignoring temporary set-backs, finding common ground, and making an
agreement on future behavior is in the best interest of our users. Will
you do it?

> *1* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341

-- 
Felipe Contreras

Re: [PATCH 0/4] remote-hg: more improvements

[Junio C Hamano]

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

> Junio C Hamano wrote:
> ...
>> I was originally led to believe that its code quality was good
>> enough, and that was why I merged the bottom three patches of the
>> series even down to 'next' in the first place.  But after seeing the
>> "Of course" response that led to [*1*], which made me recall many
>> patch-review interactions with him, I have started to have doubts.
>
> This is bullshit, and a wrong direction fallacy.
>
> Event #1:
> Junio rejects the graduation
> http://article.gmane.org/gmane.comp.version-control.git/248263
>
> Event #2:
> I give up improving remote helpers in git.git
> http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341
>
> Junio is trying to make you believe that his decision (#1) was caused by
> something I did (#2). Don't fall into that trap, #2 happened *AFTER* #1,
> it can't possibly be the cause.

I think you misunderstood.

I never said that I do not want it to graduate up (out is an option)
based on code quality.  In fact, I do not think anybody discussed
about code quality until this morning.

But because I was asked, I thought about it, and then answered
honestly.  I do not know what a trap you perceive is about, and I am
not interested in your responses.

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Junio C Hamano wrote:
> > ...
> >> I was originally led to believe that its code quality was good
> >> enough, and that was why I merged the bottom three patches of the
> >> series even down to 'next' in the first place.  But after seeing the
> >> "Of course" response that led to [*1*], which made me recall many
> >> patch-review interactions with him, I have started to have doubts.
> >
> > This is bullshit, and a wrong direction fallacy.
> >
> > Event #1:
> > Junio rejects the graduation
> > http://article.gmane.org/gmane.comp.version-control.git/248263
> >
> > Event #2:
> > I give up improving remote helpers in git.git
> > http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341
> >
> > Junio is trying to make you believe that his decision (#1) was caused by
> > something I did (#2). Don't fall into that trap, #2 happened *AFTER* #1,
> > it can't possibly be the cause.
> 
> I think you misunderstood.
> 
> I never said that I do not want it to graduate up (out is an option)
> based on code quality.

Fair enough, that was my understanding up until today.

> But because I was asked, I thought about it, and then answered
> honestly.  I do not know what a trap you perceive is about, and I am
> not interested in your responses.

Philippe Vaucher didn't ask about quality, he asked about moving out of
contrib.

-- 
Felipe Contreras

Re: [PATCH 0/4] remote-hg: more improvements

[Philippe Vaucher]

>>> It is *way* beyond the quality of any other tool in 'contrib/' and even
>>> some tools in the core, like 'git-request-pull' (which has known bugs),
>>> and probably even 'git-pt'.
>>
>> Junio, can you comment on this? I understand this probably doesn't
>> really affect the issue at hand, but it'd help clarify if it's ever
>> possible to move out of contrib/ nowadays.
>
> I was originally led to believe that its code quality was good
> enough, and that was why I merged the bottom three patches of the
> series even down to 'next' in the first place.  But after seeing the
> "Of course" response that led to [*1*], which made me recall many
> patch-review interactions with him, I have started to have doubts.
>
> The code quality of Git that many projects have come to trust their
> code with is much more than just "the code at each moment keeps
> working for the users as long as the original author is around".
> The maintainer of a port to the platform X may lose access to the
> platform after switching jobs, the maintainer of a bridge to the
> foreign system Y may stop needing to talk to the foreign system
> after completing the switch to Git.  Anybody can be hit by a bus,
> get sick, or simply lose interest in his past creations.
>
> By reading "git log contrib/remote-helpers" and comparing it with
> the logs for the rest of the system, you would realize that the
> former would not lead to a quality discussion similar to the one
> that led to [*2*], which was only possible because the change was
> adequately described to allow anybody to understand the original
> issue the change was meant to solve.  The commit that made the
> original change made it easy to ask a critical question: "You are
> improving B but at the same time breaking A.  Can we do better to
> help both A and B?"  And it allowed us to move forward without
> having to rob Peter to pay Paul.
>
> Granted, these contrib/ patches were applied with the understanding
> that contrib/ stuff can be substandard, because having anything is
> often better than having nothing, and you cannot go back in time to
> update the history to make these commits more useful to others who
> will come later.  But I would be lying if I said that I would expect
> that things will suddenly improve and that the codebase will be
> maintained for the long haul in a healthy way the minute we move it
> out of contrib/ to the core.  Especially after seeing [*1*], which
> is just one of the examples that illustrate that there clearly is no
> will to explain the changes to help others who come later to help
> maintaining the code.  "I'll take good care of the codebase", "I've
> spend the time to make it better", "Me, me, me", is not what the
> open source process is about.

Thanks for the explanation. I think it underlines well the A)
technical issues (quality commits) and the B) social issues (ability
to communicate in a friendly way & respond constructively), which we
discovered are both *essential* for contributing to git.

Neglate one or the other, and sooner or later people will refuse to
collaborate with you, because it's just too much "work" to deal with
the downsides.

My hope is that for future events of this nature to be detected sooner
and dealt with more rigidly, e.g by making it clear this or that
behavior is not acceptable. I think part of the problem here is that
we let the situation install itself, by accepting B-side issues just
because A-side was ok, hopeful that B-side would solve itself.

Philippe

Re: [PATCH 0/4] remote-hg: more improvements

[David Kastrup]

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

> Thanks for the explanation. I think it underlines well the A)
> technical issues (quality commits) and the B) social issues (ability
> to communicate in a friendly way & respond constructively), which we
> discovered are both *essential* for contributing to git.

I'm not entirely convinced of that: there is something akin to drop-dead
gorgeous code: code that is so well done that it would not matter with
regard to its maintenance whether or not its author dropped dead because
it's both done well as well as documented in a manner where the original
author could not offer significant additional help.

Of course I am a major proponent of this view because of being myself
somewhat differently endowed in the respective classes A and B, and so
having at least some sort of exchange rate between the two can, however
large the conversion fees, only benefit me...

-- 
David Kastrup

Re: [PATCH 0/4] remote-hg: more improvements

[Philippe Vaucher]

>> Thanks for the explanation. I think it underlines well the A)
>> technical issues (quality commits) and the B) social issues (ability
>> to communicate in a friendly way & respond constructively), which we
>> discovered are both *essential* for contributing to git.
>
> I'm not entirely convinced of that: there is something akin to drop-dead
> gorgeous code: code that is so well done that it would not matter with
> regard to its maintenance whether or not its author dropped dead because
> it's both done well as well as documented in a manner where the original
> author could not offer significant additional help.

I think this only means that you can get away with B issues if A's
quality is very very very high, which doens't happen very often. And I
doubt that you will be able to get away with it for long anyway, at
some point some mechanism will be put in place so the downsides of B
aren't visible to everyone... for example with the patches being sent
to one person only and this person relays it to the list while
filtering B's issues.

Philippe

Re: [PATCH 0/4] remote-hg: more improvements

[David Kastrup]

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

>>> Thanks for the explanation. I think it underlines well the A)
>>> technical issues (quality commits) and the B) social issues (ability
>>> to communicate in a friendly way & respond constructively), which we
>>> discovered are both *essential* for contributing to git.
>>
>> I'm not entirely convinced of that: there is something akin to drop-dead
>> gorgeous code: code that is so well done that it would not matter with
>> regard to its maintenance whether or not its author dropped dead because
>> it's both done well as well as documented in a manner where the original
>> author could not offer significant additional help.
>
> I think this only means that you can get away with B issues if A's
> quality is very very very high, which doens't happen very often.

I would not exactly say "get away with B issues".  It's like saying you
can get away with looking like a sleazebag if you plan the time for a
complete border search whenever traveling abroad.

Of course that means that traveling into countries where "complete
border search" might entail depriving you of your civic rights and
locking you up for decades in a torture camp without due process is
plainly not an option.

But if you are honest: everybody has to be prepared for that.  It's just
less likely to occur in practice.

Basically you have to write in a manner "if a seedy stranger gave me
that code on a street corner, I would have no problem checking it in".
In practice, the shortcuts offering themselves through civil behavior
and mutual trust get a lot more work done.

But they _are_ a vector for "social engineering".

You have to admit that it seems pretty unlikely by now that Felipe is
trying to sneak in some NSA-written code without arousing people's
suspicions.

-- 
David Kastrup

Re: [PATCH 0/4] remote-hg: more improvements

[Philippe Vaucher]

> Basically you have to write in a manner "if a seedy stranger gave me
> that code on a street corner, I would have no problem checking it in".
> In practice, the shortcuts offering themselves through civil behavior
> and mutual trust get a lot more work done.

My point was more that it's very hard to produce high quality commits
without social interaction with others explaining what you missed,
stuffs you overlooked, etc. And there B issues quickly isolate you.


> You have to admit that it seems pretty unlikely by now that Felipe is
> trying to sneak in some NSA-written code without arousing people's
> suspicions.

Not sure where I implied otherwise... and the earlier metaphore about
country borders doesn't make much sense to me.

Anyway, I think we are speaking about different things. All I'm saying
is that humans are social creatures and that thinking you can
contribute to projects ran by humans without according a high
importance to social behaviors (like Felipe thinks) is not possible.
Threads like this are proof that while technical quality might be
important for the short term, social behaviors is impossible to ignore
in the long term.

Both are very important to be an appreciated contributor, or to
contribute at all in the long term.

Philippe

Re: [PATCH 0/4] remote-hg: more improvements

[David Kastrup]

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

>> Basically you have to write in a manner "if a seedy stranger gave me
>> that code on a street corner, I would have no problem checking it
>> in".  In practice, the shortcuts offering themselves through civil
>> behavior and mutual trust get a lot more work done.
>
> My point was more that it's very hard to produce high quality commits
> without social interaction with others explaining what you missed,
> stuffs you overlooked, etc.

You are overgeneralizing.  You are assuming that it's easier for
everybody to interact with humans rather than the Tao of Computing.

> And there B issues quickly isolate you.

Unless you were isolated to start with.

> Anyway, I think we are speaking about different things. All I'm saying
> is that humans are social creatures and that thinking you can
> contribute to projects ran by humans without according a high
> importance to social behaviors (like Felipe thinks) is not possible.

You are assuming that "according a high importance to social behaviors"
is all that it takes for anybody.  Do you tell the beggar on the next
street corner that "according a high importance to earning millions"
would be all that would be necessary for him to afford anything to drink
that he'd like?

> Threads like this are proof that while technical quality might be
> important for the short term, social behaviors is impossible to ignore
> in the long term.

Not really.

> Both are very important to be an appreciated contributor, or to
> contribute at all in the long term.

The one thing where social behavior comes in is noticing who tends to be
running free software projects.

There is the mythical "scratching one's itch" theory, but it does not
fit the bill.  Those people who invest enough time into a project's
progress to make a fundamental difference tend to do it at the cost of
not having any worthwhile amount of time left actually _using_ the
product.

People mainly working on music software create very little music
themselves, people mainly working on text processing software do not
write many texts themselves, people writing high-performance operating
systems have very little use for high-performance operating systems
themselves.

All of this might have started at one time as scratching their own itch,
but once their contributions become significant, it's almost always the
itches of others they are scratching, and continue to scratch, feeling
responsible for them due to the skills they have been not as much
blessed or cursed but entrusted with.

And programming and social skills tend to be packaged separately.  So
not everybody is gifted with being able to contribute _gracefully_.

-- 
David Kastrup

Re: [PATCH 0/4] remote-hg: more improvements

[Philippe Vaucher]

>> My point was more that it's very hard to produce high quality commits
>> without social interaction with others explaining what you missed,
>> stuffs you overlooked, etc.
>
> You are overgeneralizing.  You are assuming that it's easier for
> everybody to interact with humans rather than the Tao of Computing.

No, what I'm saying is that most non-trivial patches go through a
review process involving human interactions. It is very hard to
produce a very good non-trivial patch without going through human
interactions, just because someone might ask a question about your
patch. To be honest I'm not interested in fighting over this so let's
agree to disagree.


>> Anyway, I think we are speaking about different things. All I'm saying
>> is that humans are social creatures and that thinking you can
>> contribute to projects ran by humans without according a high
>> importance to social behaviors (like Felipe thinks) is not possible.
>
> You are assuming that "according a high importance to social behaviors"
> is all that it takes for anybody.  Do you tell the beggar on the next
> street corner that "according a high importance to earning millions"
> would be all that would be necessary for him to afford anything to drink
> that he'd like?

I'm sorry that my words aren't clear enough for you to infer the point
I'm trying to make. Let's try something simpler: what I was saying is
that bad behavior will get you into trouble when contributing (and
thus it's important to behave nicely), where Felipe usualy says bad
behavior is irrelevant because only truth/quality is important.


> And programming and social skills tend to be packaged separately.  So
> not everybody is gifted with being able to contribute _gracefully_.

Yes it's unfortunate. The amount of talent in our societies that is
wasted because of communication problems is probably quite high. I
didn't find a way around "being social" in any human based community
yet, but if you have an idea please share. The only way I can see
working is that for someone to act as a mediator between the grumpy
contributor and the community, but the role of this person is not very
pleasant. That or maybe have merges done by some kind of robot with
some AI about patch quality, but I doubt it is technically feasible
yet.

Philippe

Re: [PATCH 0/4] remote-hg: more improvements

[David Kastrup]

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

> I'm sorry that my words aren't clear enough for you to infer the point
> I'm trying to make. Let's try something simpler: what I was saying is
> that bad behavior will get you into trouble when contributing (and
> thus it's important to behave nicely), where Felipe usualy says bad
> behavior is irrelevant because only truth/quality is important.

Do you feel Felipe is in control of what you label bad behavior?  Do you
feel you are in control over how you react to his behavior?

> Yes it's unfortunate. The amount of talent in our societies that is
> wasted because of communication problems is probably quite high. I
> didn't find a way around "being social" in any human based community
> yet, but if you have an idea please share.

"being social" as an isolated feat is self-contradictory.  The question
is how to function in a particular social context.  Stock answers apply
to stock behaviors and are obviously most efficient to apply.

Yesterday my girl friend bought back a mare she had sold two years ago
because its owner did not manage to get along with it.  It's a
temperamental animal that learns and performs amazingly well for its
comparatively compact build.  But it's highest in rank "or else", and so
in the end it got locked up in its stable box most of the time in order
to avoid injuries to other horses.  Now it's back here at the riding
school, and there is little question that there will be some injuries
before things settle down again even though most of the horses here know
it already.

> The only way I can see working is that for someone to act as a
> mediator between the grumpy contributor and the community, but the
> role of this person is not very pleasant. That or maybe have merges
> done by some kind of robot with some AI about patch quality, but I
> doubt it is technically feasible yet.

Well, humans are more complex.  There are no sure-fire recipes even for
working with horses: some of them here have their separate paddocks
because things would not settle down, some of them have standard
conflicts, there are occasional injuries.  The most important "standard
recipe" is to make sure that the areas accessible to multiple horses do
not have dead ends small enough for one horse to be able to corner
another.  That's not really fabulous but still pretty essential.  Also
enough room all around, obviously.

Now humans are often held in conditions that are not species-appropriate
and lead to a buildup of tension.  Try finding an undisturbed spot in a
typical city suitable for devouring a bread roll you hunted down without
getting other predators eyeing your prey.  Almost impossible.

It may be that distributed version control systems offer more
possibilities for organizing cooperation in a manner leaving graceful
escape paths when things don't work out.  It's not what one want to have
to rely on permanently but it may be worth thinking about ways to make
consequences from difficulties less "inevitable" and/or grave.

-- 
David Kastrup

Re: [PATCH 0/4] remote-hg: more improvements

[Philippe Vaucher]

>> I'm sorry that my words aren't clear enough for you to infer the point
>> I'm trying to make. Let's try something simpler: what I was saying is
>> that bad behavior will get you into trouble when contributing (and
>> thus it's important to behave nicely), where Felipe usualy says bad
>> behavior is irrelevant because only truth/quality is important.
>
> Do you feel Felipe is in control of what you label bad behavior?  Do you
> feel you are in control over how you react to his behavior?

I feel that Felipe cannot control this (or decided not to), and I feel
that I am pretty much in control of my reactions given I am able to
not "give in" to the burst of emotions that some of his behavior can
trigger. For the record I'm not really blaming Felipe for what he
does, I'm saying a solution has to be found to prevent his behavior
from harming people, and that a solution that involves everyone
adapting to Felipe is not reasonable.


> Yesterday my girl friend bought back a mare she had sold two years ago
> because its owner did not manage to get along with it.  It's a
> temperamental animal that learns and performs amazingly well for its
> comparatively compact build.  But it's highest in rank "or else", and so
> in the end it got locked up in its stable box most of the time in order
> to avoid injuries to other horses.  Now it's back here at the riding
> school, and there is little question that there will be some injuries
> before things settle down again even though most of the horses here know
> it already.

I think that is the point: behave properly or be isolated to avoid
harming others. Wether you control your behavior or not has little to
do with it, it's your behavior that counts. That's how it works in
pretty much any communities I know of.


> It may be that distributed version control systems offer more
> possibilities for organizing cooperation in a manner leaving graceful
> escape paths when things don't work out.  It's not what one want to have
> to rely on permanently but it may be worth thinking about ways to make
> consequences from difficulties less "inevitable" and/or grave.

Sure, I believe my proposal of acting on bad behavior earlier would
prevent incidents like this one, because it would defuse situations
before they settle in. But that's just a proposal, I'm just an
observer here.

Philippe

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

Philippe Vaucher wrote:
> >> I'm sorry that my words aren't clear enough for you to infer the point
> >> I'm trying to make. Let's try something simpler: what I was saying is
> >> that bad behavior will get you into trouble when contributing (and
> >> thus it's important to behave nicely), where Felipe usualy says bad
> >> behavior is irrelevant because only truth/quality is important.
> >
> > Do you feel Felipe is in control of what you label bad behavior?  Do you
> > feel you are in control over how you react to his behavior?
> 
> I feel that Felipe cannot control this (or decided not to),

I am pretty much in control of my behavior. Those who know me personally
know that I *never* get angry.

The problem is that what you label as "bad behavior" I do not. For
example the atheist billboard that said "You KNOW it's a Myth. This
Season, Celebrate REASON!" caused a lot of furor, and people all over
U.S.A. said "you cannot say that!", "that's offensive!", "it's a war
against Christmass", "that shouldn't be tolerated in modern
society", and so on.

Of course, it should be tolerated in a modern society, and it should not
be offensive, those are facts. Of course people can disagree with those
facts (but those people are wrong).

The atheists are not engaging in bad behavior, it's just that the
majority constituted by religious and bend-over-backwards-liberals have
a different definition of "bad behavior" (a wrong definition).

So if somebody convinced me that my behavior is indeed bad, I would certainly
change it, but I do not think it's "bad". Just the same way nobody has
convinced many atheists that their behavior in those billboards is bad.
And they can't convince them, because they would need logic, reason, and
evidence, and the atheists have them.

> > Yesterday my girl friend bought back a mare she had sold two years ago
> > because its owner did not manage to get along with it.  It's a
> > temperamental animal that learns and performs amazingly well for its
> > comparatively compact build.  But it's highest in rank "or else", and so
> > in the end it got locked up in its stable box most of the time in order
> > to avoid injuries to other horses.  Now it's back here at the riding
> > school, and there is little question that there will be some injuries
> > before things settle down again even though most of the horses here know
> > it already.
> 
> I think that is the point: behave properly or be isolated to avoid
> harming others. Wether you control your behavior or not has little to
> do with it, it's your behavior that counts. That's how it works in
> pretty much any communities I know of.

Except the largest and most important communities; countries. In the
vast majority of countries what is labeled as "bad" (a.k.a. illegal) has
had much more consideration (millenia) than in most online communities
(barely decades). Saying something is stupid might be considered "bad" to
some people, but not all, so you can't get thrown in jail for doing
that, even though some peple thing it's "harming others". For example,
saying "religion is stupid". In order to be thrown in jail you have to
do something _truly_ bad, something we all agree is harming others.

In online communities facts don't matter, if the majority thinks you are
doing something bad (even if you are not), you get thrown to jail (or
virtual jail).

> > It may be that distributed version control systems offer more
> > possibilities for organizing cooperation in a manner leaving graceful
> > escape paths when things don't work out.  It's not what one want to have
> > to rely on permanently but it may be worth thinking about ways to make
> > consequences from difficulties less "inevitable" and/or grave.
> 
> Sure, I believe my proposal of acting on bad behavior earlier would
> prevent incidents like this one, because it would defuse situations
> before they settle in. But that's just a proposal, I'm just an
> observer here.

What you label "bad behavior" started *because* of Junio's decision.

Junio made an important (to me) decision based on a *TECHNICAL* reason
he never explained. My "bad behavior" basically consisted in pointing
out Junio's bad behavior.

In this case I'm not very dissimilar to Edward Snowden. Snowden did
somethig "bad" in the eyes of many people, but he did it *because* of
something deeper and more important. It was the government that caused
Snowden's actions, and it is the government's bad behavior that is
important. But if you look at the mass media, they don't concentrate on
the government's actions (that's risky), they concentrate on Snowden.

This might have changed after Snowden gained support, but at least
initially it was this way.

You are doing exactly the same as the mass media. Instead of looking at
the actions of Junio, namely his *TECHNICAL* decision which *triggered*
my "bad behavior", you look at me, the easy target, and ignore the real
problem.

Wait, wait! Before focusing on deciding whether leaking documents is
"bad", and how exactly it was carried out, why don't you concentrate on
the real issue; the fact that the government is spying on everyone. Nah!
that's haaard. Let's obliterate the little guy.

-- 
Felipe Contreras

Re: [PATCH 0/4] remote-hg: more improvements

[David Kastrup]

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

> Philippe Vaucher wrote:

[...]

>> > Do you feel Felipe is in control of what you label bad behavior?  Do you
>> > feel you are in control over how you react to his behavior?
>> 
>> I feel that Felipe cannot control this (or decided not to),
>
> I am pretty much in control of my behavior. Those who know me
> personally know that I *never* get angry.

You are missing the point.  The point is not what effect your behavior
has on you but what it has on others.  As you are unable to attribute
feelings to others (like you appear unable to attribute reason to them),
you are unable to control it.

It's like repairing clockwork when your hands are numb and have never
been otherwise.

"When something does not work, apply extra force" does not work with
clockwork.  It does not work with people, either.

> The problem is that what you label as "bad behavior" I do not.

It does not matter what you or others want to label it.  The effects are
there anyway.

> So if somebody convinced me that my behavior is indeed bad, I would
> certainly change it, but I do not think it's "bad".

What effect your behavior has on others is not dependent on what you
think about it.

If you convinced yourself to be standing perfectly balanced and find
yourself falling, there is no point in not catching yourself before
smashing your head open just because you _know_ you have been standing
perfectly upright.

-- 
David Kastrup

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

David Kastrup wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Philippe Vaucher wrote:
> 
> [...]
> 
> >> > Do you feel Felipe is in control of what you label bad behavior?  Do you
> >> > feel you are in control over how you react to his behavior?
> >> 
> >> I feel that Felipe cannot control this (or decided not to),
> >
> > I am pretty much in control of my behavior. Those who know me
> > personally know that I *never* get angry.
> 
> You are missing the point.  The point is not what effect your behavior
> has on you but what it has on others.

If me saying "I do not believe in God" has a negative effect on Mark,
your answer seems to be "do not tell Mark the truth". If Mark was a
co-worker and I had no option but to interact with him, I would probably
do something along those lines if possible. But if Mark was a member of
an open source project, I do have an option and I'd rather tell it like
it is. If Mark has a problem with that, I can always avoid Mark, or just
leave the project (say if Mark was the maintainer).

In both cases Mark is wrong. I do understand that most people would
rather comprimise their beliefs in order to win penguing points. I'm
not that way.

If I can't speak my mind in an open source project where I'm
contributing my time *for free*, I do not want to be part of that
project. It's the project that's wrong, not me, and it's the project
that looses, not me.

-- 
Felipe Contreras

Re: [PATCH 0/4] remote-hg: more improvements

[David Kastrup]

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

> David Kastrup wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> 
>> > Philippe Vaucher wrote:
>> 
>> [...]
>> 
>> >> > Do you feel Felipe is in control of what you label bad behavior?  Do you
>> >> > feel you are in control over how you react to his behavior?
>> >> 
>> >> I feel that Felipe cannot control this (or decided not to),
>> >
>> > I am pretty much in control of my behavior. Those who know me
>> > personally know that I *never* get angry.
>> 
>> You are missing the point.  The point is not what effect your behavior
>> has on you but what it has on others.
>
> If me saying "I do not believe in God" has a negative effect on Mark,
> your answer seems to be "do not tell Mark the truth".

Shouting "your God is an imaginary shithead" every time you see Mark and
asking everybody in the room "Isn't it right that Mark's God is an
imaginary shithead?  Can anybody here testify having seen him?" whenever
anybody is there, and occasionally calling him and others on the phone
when you have nothing else to do and tell him that you consider his God
an imaginary shithead and him a gullible fool to believe otherwise...

Do you really think that's the way you are going to earn people's
respect?  By prouding yourself on having seen through Mark's purported
stupidity and pointing it out to everybody?

> But if Mark was a member of an open source project, I do have an
> option and I'd rather tell it like it is.

And everybody else, of course, is wrong about it.  And only you are
right.  All you need to do is to be as obnoxious as you can manage, and
you'll win everyone over to your side.

Don't kid yourself: you are doing this entire sad spectacle only to
satisfy your own self-righteousness, just to be able to tell yourself
"all those people working on Git with the exception of myself are
pitiable fools and/or bad persons letting Junio pull the wool over their
eyes".

You've made your point.  People don't agree with it.  Repeating your
point over and over will not change that.

> If Mark has a problem with that, I can always avoid Mark, or just
> leave the project (say if Mark was the maintainer).
>
> In both cases Mark is wrong. I do understand that most people would
> rather comprimise their beliefs in order to win penguing points. I'm
> not that way.

No, you rather compromise your standing in order to win your beliefs.
Take them.  They are yours.  Nobody else wants them.  Even if there
would have been merit in them originally, after revomiting them a dozen
times on people's laps they just want the stench to go away.

> If I can't speak my mind in an open source project where I'm
> contributing my time *for free*, I do not want to be part of that
> project. It's the project that's wrong, not me, and it's the project
> that looses, not me.

Well, you are a sore winner for sure.

-- 
David Kastrup

Re: [PATCH 0/4] remote-hg: more improvements

[Junio C Hamano]

David Kastrup <dak@gnu.org> writes:

> Philippe Vaucher <philippe.vaucher@gmail.com> writes:
>
>> Thanks for the explanation. I think it underlines well the A)
>> technical issues (quality commits) and the B) social issues (ability
>> to communicate in a friendly way & respond constructively), which we
>> discovered are both *essential* for contributing to git.
>
> I'm not entirely convinced of that: there is something akin to drop-dead
> gorgeous code: code that is so well done that it would not matter with
> regard to its maintenance whether or not its author dropped dead because
> it's both done well as well as documented in a manner where the original
> author could not offer significant additional help.

I would have to say that you are living in a fantasy land.  During
the entire life of Git, I do not think I ever saw such a code that
is perfect from the get-go and did not require any maintenance to
adjust to the changing time.

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

David Kastrup wrote:
> Shouting "your God is an imaginary shithead" every time you see Mark

There's no point in discussing with an unconstructive person as you.
I've made my point, you are just talking nonsense.

Every rational person on this list knows that if I wanted to, I could be
much more offsensive and insulting.

-- 
Felipe Contreras

Re: [PATCH 0/4] remote-hg: more improvements

[David Kastrup]

Junio C Hamano <gitster@pobox.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Philippe Vaucher <philippe.vaucher@gmail.com> writes:
>>
>>> Thanks for the explanation. I think it underlines well the A)
>>> technical issues (quality commits) and the B) social issues (ability
>>> to communicate in a friendly way & respond constructively), which we
>>> discovered are both *essential* for contributing to git.
>>
>> I'm not entirely convinced of that: there is something akin to drop-dead
>> gorgeous code: code that is so well done that it would not matter with
>> regard to its maintenance whether or not its author dropped dead because
>> it's both done well as well as documented in a manner where the original
>> author could not offer significant additional help.
>
> I would have to say that you are living in a fantasy land.  During
> the entire life of Git, I do not think I ever saw such a code that
> is perfect from the get-go and did not require any maintenance to
> adjust to the changing time.

You are attacking a straw man.  "where the original author could not
offer significant _additional_ help" does not at all equate "does not
require any maintenance".

-- 
David Kastrup

Re: [PATCH 0/4] remote-hg: more improvements

[Junio C Hamano]

David Kastrup <dak@gnu.org> writes:

>>> I'm not entirely convinced of that: there is something akin to drop-dead
>>> gorgeous code: code that is so well done that it would not matter with
>>> regard to its maintenance whether or not its author dropped dead because
>>> it's both done well as well as documented in a manner where the original
>>> author could not offer significant additional help.
>>
>> I would have to say that you are living in a fantasy land.  During
>> the entire life of Git, I do not think I ever saw such a code that
>> is perfect from the get-go and did not require any maintenance to
>> adjust to the changing time.
>
> You are attacking a straw man.  "where the original author could not
> offer significant _additional_ help" does not at all equate "does not
> require any maintenance".

Ahh, I realize that I misread what you wrote.  Yes, I do agree with
you that we have a lot of pieces of code, with log messages we can
find with the help of blame, that the author himself does not need
to be present for them to be maintained properly.  Making all the
code in Git like that may be an unattainable goal, but calling the
effort to make that happen "living in a fantasy land" is utterly
wrong.  Sorry about confusion.

Re: [PATCH 0/4] remote-hg: more improvements

[David Kastrup]

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

> David Kastrup wrote:
>> Shouting "your God is an imaginary shithead" every time you see Mark
>
> There's no point in discussing with an unconstructive person as you.

So go to a constructive person you call your friend and show him one of
your calm rational mails and ask him for his opinion.  Did you do so?
Why not?  Are you so infallible in communication that a second opinion
from someone you trust would be irrelevant?  Or is there nobody you
trust?

> I've made my point, you are just talking nonsense.
>
> Every rational person on this list knows that if I wanted to, I could
> be much more offsensive and insulting.

It would not appear that there any rational persons on this list apart
from you.  Not that it matters.  I think that all the other irrational
people on this list are rather more interested in your potential of
being less offensive and insulting.  Once the cure is worse than the
ailment, namely you cause fewer work to be done on Git by your presence
than you can do yourself, because of you distracting others and/or
making them leave, it does not matter whether it could be even worse.

-- 
David Kastrup