Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

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

 



On Tue, Apr 16, 2013 at 5:45 PM, Phil Hord <phil.hord@xxxxxxxxx> wrote:
> On Tue, Apr 16, 2013 at 3:04 PM, Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
>> On Tue, Apr 16, 2013 at 4:59 AM, Thomas Rast <trast@xxxxxxxxxxx> wrote:
>>> A cursory look^W^Wreview of the messages in fc/remote-hg:
>>
>> [skipping irrelevant comments]
>>
>> I'm sorry, did you actually hit an issue that required to look at the
>> commit message to understand where the issue came from? No? Then I
>> won't bother with hypotheticals.
>>
>> If you want to waste your time, by all means, rewrite all my commit
>> messages with essays that nobody will ever read. I'm not going to do
>> that for some hypothetical case that will never happen. I'm not going
>> to waste my time.
>
> This is not a hypothetical.  Almost every time I bisect a regression
> in git.git, I find the commit message tells me exactly why the commit
> did what it did and what the expected result was.  I find this to be
> amazingly useful.  Do I need to show you real instances of that
> happening? No.  I promise it did, though.

Yes please. Show me one of the instances where you hit a bisect with
any of the remote-hg commits mentioned above by Thomas Rast.

> Of course, 99% of the commit messages may never be useful to me or
> anyone else.  But we do not eschew them altogether.  The 1% I have to
> rely on are nearly always helpful and clear, and that is the part I
> care about.

And how do you know this will be part of the 1%? You don't. How many
times have you tracked regressions in transport helper's import/export
functionality? How many times in remote-hg? How many times has
*anybody* done so?

> If you will not waste your time to write a decent commit message, why
> do you waste our time asking us to review and accept ill-defined
> patches?

Because it *fixes a problem*. And a commit essay doesn't fix any,
because nobody will ever go back in history and wonder, hey, what is
up with this commit. If somebody does, then I will accept that commit
essays are always a must. But it won't happen.

> Here, of course, I use the royal "us" as I do not review
> your patches.  I do not know why that is; I suppose you patch things
> outside of my interests, but it may also be that your patches are
> simply incomprehensible by design.

Yeah, but that's the thing, if you don't understand the code the
patches are changing, then how can you know the commit message is
sufficient to figure things out when a regression is found? You don't.
You can't.

Let's face the truth, you are advocating for stopping progress on the
name that something might happen sometime in the feature, although
most likely won't. When in reality, it just won't.

And you are not saying "it would be nice to have full commit essay",
you are saying: "without a commit essay this patch should NOT be
merged", even more "without a commit essay this patch should NOT be
considered a cooking patch".

I think the commit message is fine, you don't. So YOU go ahead and
write the proper one. If you don't, all you are doing is being an
impediment to progress.

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]