Re: [PATCH 1/2] transport-helper: report errors properly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 11, 2013 at 11:59 AM, Jeff King <peff@xxxxxxxx> wrote:
> On Thu, Apr 11, 2013 at 11:49:11AM -0500, Felipe Contreras wrote:
>
>> > I am OK with adding the test for import as a separate patch. What I am
>> > not OK with (and this goes for the rest of the commit message, too) is
>> > failing to explain any back-story at all for why the change is done in
>> > the way it is.
>> >
>> > _You_ may understand it _right now_, but that is not the primary
>> > audience of the message. The primary audience is somebody else a year
>> > from now who is wondering why this patch was done the way it was.
>>
>> Who would be this person? Somebody who wonders why this test is using
>> "feature done"? I doubt such a person would exist, as using this
>> feature is standard, as can be seen below this chunk. *If* the test
>> was *not* using this "feature done", *then* sure, an explanation would
>> be needed.
>
> If it was so obvious, why did your initial patch not use "feature done"?

Because I didn't want to test the obvious, I wanted to test something else.

> If it was so obvious, why did our email discussion go back and forth so
> many times before arriving at this patch?

This patch has absolutely nothing to do with that, in fact, forget
about it, such a minor check is not worth this time and effort:
http://article.gmane.org/gmane.comp.version-control.git/220899

> It was certainly not obvious to me when this email thread started. So in
> response to your question: *I* am that person. I was him two weeks ago,
> and there is a good chance that I will be him a year from now.

No, you are not. I didn't send a patch with "feature done" originally,
the only reason you wondered about the patch with "feature done" is
that you saw one without it. It will _never_ happen again.

> Much of
> my work on git is spent tracking down bugs in older code, and those
> commit messages are extremely valuable to me in understanding what
> happened at the time.

Lets make a bet. Let's push the simpler version, and when you hit this
commit message retrospectively and find that you don't understand what
is happening, I loose, and I will forever accept verbose commit
messages. It will never happen.

> But I give up on you. I find most of your commit messages lacking in
> details and motivation, making assumptions that the reader is as
> familiar with the code when reading the commit as you are when you wrote
> it. I tried to help by suggesting in review that you elaborate. That
> didn't work. So I tried to help by writing the text myself. But clearly
> I am not going to convince you that it is valuable, even if it requires
> no work at all from you, so I have nothing else to say on the matter.

Me neither. I picked your solution, but that's not enough, you
*always* want me to do EXACTLY what you want, and never argue back.

It's not going to happen. There's nothing wrong with disagreeing.

Cheers.

--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]