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

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

 



Thiago Farina <tfransosi@xxxxxxxxx> writes:

> On Thu, Sep 17, 2009 at 7:00 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Thiago Farina <tfransosi@xxxxxxxxx> 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.

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.

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.

And that somebody _could_ be you.
--
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]