Re: [PATCH v3] Trivial fix: Make all the usage strings to use the same pattern.

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

 



Thiago Farina <tfransosi@xxxxxxxxx> writes:

> On Tue, Sep 22, 2009 at 4:05 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> What does this _fix_?
> The answer here is nothing. But I think the benefit is to a have a
> pattern, but if it is _not_ desired, I can stop here.

That was not what I asked.

    What does this _fix_?  Does the benefit of this patch outweigh the
    cost, and if it does, in what way?

Does the benefit of "having a pattern" outweigh the cost of this patch?

That was the primary question.

The same patch, depending on the time it is considered for inclusion, can
have different cost.  Because it is about cost vs benefit ratio, asking
"is it desired?" has no black/white answer.

If we were writing git from scratch, we would have written things in a way
that matches a certain pattern, so the answer to the question for any
"needless churn to bring a pattern in" patch would be "yes", but that is
only true if we _were_ writing git from scratch.

But because we are not, changes involve some cost. Is it worth the pain?
What is the best way to minimize the pain, and when is the best time to
apply such a patch?  These are the concerns a maturing project has to
worry about a patch like this.

The answer at this point is a _very_ qualified "maybe".  Yes, if it were
pain-free, having a pattern would be much better than not having one.  If
on the other hand if that means people need to re-re-review 2500 lines of
patch every 15 minutes and I have to resolve needless conflicts,...

If I were you, I'd pretend as if I have only one chance left, and try to
come up with a perfect [*1*] patch that does not touch any file that is
different between master and next, and follow it up with a set of separate
patches for files that are different between master and next, one patch
per file.


[Footnote]

*1* that means no "Huh?  Why is bisect_helper's usage named differently
from others?" kind of glitches anywhere.
--
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]