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

[Thiago Farina <tfransosi@gmail.com>]

On Thu, Sep 17, 2009 at 9:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Thiago Farina <tfransosi@gmail.com> writes:
>
>> On Thu, Sep 17, 2009 at 7:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Thiago Farina <tfransosi@gmail.com> writes:
>>>
>>>> +static const char pack_usage[] =
>>>> +  "git pack-objects [{ -q | --progress | --all-progress }] \n"
>>>> +  "        [--max-pack-size=N] [--local] [--incremental] \n"
>>>> +  "        [--window=N] [--window-memory=N] [--depth=N] \n"
>>>> +  "        [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset] \n"
>>>> +  "        [--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog] \n"
>>>> +  "        [--stdout | base-name] [--include-tag] \n"
>>>> +  "        [--keep-unreachable | --unpack-unreachable] \n"
>>>> +  "        [<ref-list | <object-list]";
>>>
>>> Do you still want to keep the trailing whitespace on these lines?
>> I did this to maintain the same output of the old string, but if you
>> want I can change, what you suggest?
>
> If you need to add or remove an option to actually _change_ the string, a
> patch like this, as a preparatory step before the real improvement, would
> be a very welcome clean-up.  I however would suggest doing nothing, if
> this is the only patch you are going to send against this program in the
> near future, to be honest.
OK.
>
> Even though we do not have any other patch in flight that changes this
> program at this moment (as expected, because we are in -rc freeze), which
> means there is not much risk for this patch to cause needless conflicts
> with others, we generally avoid code churn like this one, as a principle
> for a maturing project.
This release candidate freeze is a period that no one can send patches?
If you could, point me to a documentation about how is the development
process adopted by git.
As I can see, anybody can send patches to this mailing list for
review, but if no one cares about the my patch for example, it doesn't
get a review and any feedback.
In a web review tool, the patch is assigned to someone review it, but
here it is impossible, so how the things are tracked here? Only you
merge the patches into the master branch? When someone send a patch,
you get it, make a topic-branch in your private repository, and if it
is good it will be merged into 'pu branch'? And what did you mean with
code churn?
>
> The _very best_ thing you can do for the project on this particular issue
> is to keep an eye on the list and the next time somebody wants to patch
> this program in a way that affects the usage string, remind that person to
> first clean-up the string without changing anything else as a preparation
> patch; I however admit that I am asking a lot more work out of you.
>
> A real improvement patch from that somebody _could_ be to remove the
> trailing whitespaces from the output string, and in that case I would not
> mind if two patches (one preparatory patch which is this one, and the
> other being the removal of trailing whitespaces) were squashed together.
> In fact, in such a trivial case, it probably be better to squash them into
> one.
If I understand correctly, do you want a function to remove the
trailing whitespace from a given string? Like the functions that work
with whitespaces in ws.c?
>
> And that somebody _could_ be you.
>