Re: [PATCH] Avoid the use of backslash-at-eol in pack-objects usage string.

From: Thiago Farina <tfransosi@gmail.com>
Date: Sep 18, 2009, 21:40 UTC
Message-ID: <a4c8a6d00909181440l5c8b0193k4703af8d06dde9b0@mail.gmail.com>
In-Reply-To: <7v1vm49ifb.fsf@alter.siamese.dyndns.org>

On Fri, Sep 18, 2009 at 4:11 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 12 quoted lines

> Thiago Farina <tfransosi@gmail.com> writes:
>
>> This release candidate freeze is a period that no one can send patches?
>
> No.
>
> After -rc1, only fixes to regressions and severe bugs and trivially
> correct documentation patches will be applied to my tree, but all other
> kinds of patches are still sent to the list for discussion, so that the
> proposed changes can be discussed, polished and then become ready for the
> development cycle after the upcoming release.
> I often even pick them up and queue them to 'pu' and possibly 'next' as time permits.

If you don't want to pick a patch this means that it was not accepted, right? I wrote others two trivial patches, one has comments, and I did the changes suggested, but I guess not will be done about it because it is just trivial.

Show 14 quoted lines

>> And what did you mean with code churn?
>
> A change primarily for the sake of change without urgency nor real benefit
> in the longer term.
>
> It bothers nobody if a long literal string is written as a string literal
> in a dq pair with LFs quoted with backslashes, or as a run of multiple
> string literals, each of which ending with LF, to be concatenated by the
> compiler.  It however would bother somebody who actually wants to modify
> these lines for a real change, and that is the best time for doing such a
> clean-up.  Reasons for such a real change vary; to fix earlier mistakes
> (e.g. one line being excessively longer than others, or an option is
> misspelled), to add a new option, or to make the output of the program
> easier to read in general, etc.

This means that trivial patches like this one I wrote are generally not accepted? Why is there this difficult (is it to maintain the high level of the patches)? I thought if it is trivial it can be merged after a review, into one of the integration branches. You write the comments (the people in mailing list), I make the changes, and then the patch is committed. But what I'm seeing here, this is not how the things are done here. It is much more complicated than that I guess.

In a codereview tool I can send a patch for review, I can assign it to someone review, he will make comments, I will make the necessary changes, and when the patch is ready, it will be committed. What is the workflow? With an email I can't assign a patch to someone, with time it will be lost.

I'm just trying to understand what I have to do, to submit better patches. Another issue that I saw, is about *issues* or bugs, they are not tracked in a bug traker. It's just an email, so how can I work in a bug if I don't know about it, have I to find the bugs myself?