please stop referring to "facts" and "obvious". You pretend to be a being of
pure reason and that everything you say is logical, drawn from facts. But you
forget or perhaps do not know that logic by itself proofs nothing, it all
depends on the axioms you impose. And yours are quite different from what
others consider as such, and apparently also inconsistent.
So, instead of trying to twist things around so that broken things in your code
are not broken after all, why not simply re-roll your patch with the "obvious"
fixes applies? As you write yourself, time is not pressing at all -- so I don't
see why your patch should be merged now, and fixed later, contrary to how other
people's patches are treated? Why not fix them first, and then apply? We do
have time, after all! And nobody is expecting you to do that while you are on
vacation, either. Nor that you do it instantly.
Just say: "OK, I see there is a problem with the patches; even though I
consider it unimportant, I will play by the rules everybody here has to follow,
and re-roll the patch series. But this is of low priority for me, so I cannot
say right now when it will happen".
Everybody would be happy then. Except perhaps the hypothetical users, who would
have to wait a bit longer -- but oh, not really, because they can just use
remote-bzr from your repo, yay :-). I really like that about it, it lives in
contrib, so one can use it w/o it being merged into git.git.
Instead, you make claims that make you look like a foolish and arrogant ass,
all the while insulting Junio and me implicitly. Why do you do that??? It
delays acceptance of your nice work. As you write, this hurts the users. So why
Since you keep complaining that nobody ever really can point to anything wrong
your said, I'll do you the favor by deconstructing one of the claims you made:
On 13.12.2012, at 20:06, Felipe Contreras wrote:
> On Thu, Dec 13, 2012 at 6:04 AM, Max Horn <post...@quendi.de> wrote:
>> On 13.12.2012, at 11:08, Felipe Contreras wrote:
>>> On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano <gits...@pobox.com> wrote:
>>>> Felipe Contreras <felipe.contre...@gmail.com> writes:
>>>>>> New remote helper for bzr (v3). With minor fixes, this may be ready
>>>>>> for 'next'.
>>>>> What minor fixes?
>>>> Lookng at the above (fixup), $gmane/210744 comes to mind
>>> That doesn't matter. The code and the tests would work just fine.
>> It doesn't matter? I find that statement hard to align with what the
>> maintainer of git, and thus the person who decides whether your patch series
>> gets merged or not, wrote just above? In fact, it seems to me that what
>> Junio said matters a great deal...
> So you think Junio knows more about remote-bzr than I do?
This is a classical straw man argument. No, I do not think that. But I do think
that Junio knows enough to review your code, and I do think that the point he
raised is valid. You disagree with the importance of his point
> I repeat; it
> doesn't affect the tests, it doesn't affect the code, it doesn't cause
> any problem. remote-bzr could be merged today, in fact, it could have
> been merged a month ago.
> You don't trust me? Here, look:
> All this code is a no-op, because, as Junio pointed out, cmd is null.
> How is that a problem? It's not.
It is a problem. Because either the code inside the if is important, and then
this is a bug. Or it is not important -- then it should not be there in the
Either way, the patch series should be re-rolled. Of course in a whatever time
frame suits you. If you are not willing to do that, this is sad, but of course
also your right!
>> This is a very strange attitude...
>> In another email, you complained about nobody reviewing your patches
>> respectively nobody voicing any constructive criticism. Yet Junio did just
>> that, and again in $gmane/210745 -- and you replied to neither, and acted on
>> neither (not even by refuting the points brought up), and now summarily
>> dismiss them as irrelevant. I find that quite disturbing :-(.
> I didn't say it was irrelevant, it should be fixed,
Actually, you wrote:
"That doesn't matter."
So I paraphrased. In any case, I am glad to hear you finally agree that it
should be fixed (which you did *not* say in your initial reply). So the problem
we have seems to be that you do not understand how patches typically handled in
git.git. Well, based on my observation: If reviews point out things in a patch
series that are not optimal or even broken, it is expected that the submitter
fixes this locally and resubmits a new version of the series. In some cases, it
is possible to make exceptions, e.g. trivial typo fixes can be applied on the
fly. But otherwise, you re-roll, you do not get your stuff merged just based on
the promise that you'll submit a series of fixes later. Esp. if the fixes are
Of course more exceptions can be made, but based on what I saw, this is rare,
and has to be justified quite well. I fail to see a justification in this
case... You mentioned "the users" but AFAIK there are no known users yet, and
even if, they can simply use remote-bzr from your tree.
This could perhaps be documented explicitly in Documentation/SubmittingPatches.
Not sure if I think this would be a good idea or even helpful, just thinking
> but Junio said
> "With minor fixes, this may be ready for 'next'." which is no true
> IMO, it's ready *now*, it was ready one month ago. For 'next', this
> problem doesn't matter.
> The feedback is appreciated, but delaying the merging of this code for
> no reason makes little sense to me.
And here goes the insult. You say Junio has no reason to delay the merging.
When you really mean that you don't agree with his reasons. So you attack his
professionalism and integrity by alluding that he has some ulterior motives to
delay the patch. E.g. that he is hates you, is just mean, does it out of
> Junio, of course, can do whatever he wants. The removal of this no-op code
> can wait, or it can be done
> on top of v3, there's no need for re-roll, and Junio already
> complained about the v3 re-roll.
> And I didn't act because I was on vacations, git development is not my
> only priority.
Of course. Nobody is complaining that you take too long to reply. We are just
unhappy in the way you reply when you do reply :-(.
> And even if I had time, I don't see why I should
> prioritize this fix, it's not important, the code is ready.
Another straw man: Nobody asked you to prioritize the fix, take your time. It
was you who asked that the series should be applied without any further fixes.
>>>> but there may be others. It is the responsibility of a contributor to keep
>>>> track of review comments others give to his or her patches and
>>>> reroll them, so I do not recall every minor details, sorry.
>>> There is nothing that prevents remote-bzr from being merged.
>> Well, I think that is up to Junio to decide in the end, though :-). He wrote
> No. He can decide if the code gets merged, but he is not the voice of
> truth. Nothing prevents him from merging the code, except himself.
> There is no known issue with the code, that is a true fact.
Here are a multitude of fallacies hidden, partially explainable by a differing
set of axioms, and/or shear arrogance.
Let us re-reread what was said: Initially, you claimed that "There is nothing
that prevents remote-bzr from being merged".
Now, it wasn't said in the above, but let me make it explicit: This statement
is "obviously" wrong. There are parts of the patch series Junio thinks are
not up to par, and he made it quite clear that he will not merge it until these
things are resolved.
Hence, ignoring all else, there obviously *is* something that prevents
remote-bzr from being merged. That is a "fact". You even admit so yourself,
also contradicting yourself:
"Nothing prevents him from merging the code, except himself."
So how is it possible that you can claim that there is nothing that prevents
the merge? Ignoring the self-contradicting aspects of what you wrote, the basis
for your differing conclusion seems to be that you change the terms of
discussion and are using a different set of axioms. In particular, you
"things that prevent remote-bzr from being merged"
"things that in Felipe's view prevent remote-bzr from being merged".
Of course one can arbitrarily bend the rules by this definition. For example,
we could redefine "nothing prevents the merge" as
"no technical reasons prevent the merge", and the latter is indeed quite true;
your patch series applies perfectly fine, git can do that. Of course the same
holds for a patch which removes git.c from the repository, so I don't think
this definition is particularly useful...
Back to your self-contradictory statement: It could be parsed as an (not
well-formed) attempt to say that Junio has no objective reasons to reject your
patch. I.e. you again imply that Junio's decision that the patch is not
merge-ready is not based upon "logical conclusions from the given set of
facts". Indeed, I would dare say that many people on the list will have
interpreted your statements this way... At least I did.
This is something what a lot of people would consider a strong insult towards
the professionalism and integrity of Junio. There are more examples of this in
previous communications between you and other people in the list.
You finally add "There is no known issue with the code, that is a true fact.".
Within your axiom set, this is certainly true. It certainly is not true in mine
or Junio's... Yet you very strongly emphasis with your statement that your set
of axioms is the correct one to use here, although I would guess that most
people would disagree.
This is especially arrogant in view of the another straw man argument you are
employing: By writing "[Junio] he is not the voice of truth.", you implicate
that I or anybody were of this opinion. But I am not, and what I wrote cannot
logically be construed as saying so. At least not within what most people would
consider as axiom set; of course if your axiom set includes "Max believes Junio
is the voice of truth", your claim because truth, albeit a tautological one.
But let me make clear that any such axioms, or set of axioms leading to that
implicating, are inconsistent: In my view, of course Junio is fallible and
makes mistakes, and can be wrong etc. -- like any human being. Including most
definitely me and you.
This is a horrible way of working within a team effort :-(. I find this a great
pity, because I believe you are doing some really nice work, I esp. like your
remote-hg which works much better for me than the others I tried so far.
 As a mathematician, I was taught to avoid the word "obvious" in any
written form of proof, as it makes you sound arrogant, and it also discourages
the reader from thinking critical about a statement, which is considered
extremely bad. But since you like it so much, I am using here on purpose.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html