Thiago Farina <tfransosi@xxxxxxxxx> 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. > 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'? "A note from the maintainer" I send out every once in a while (also can be seen at http://members.cox.net/junkio/) explains how things work. > 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. >> 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... No. What I meant was that I might have said it is a real improvement if your patch also removed the trailing whitespace from the literal string, as I hinted in my original response. Such a submission may have looked like this. Notice that the changing of the style for multi-line string literal is "while at it". I called a patch whose only change falls into that category a needless code churn. -- >8 -- Subject: [PATCH] pack-objects: remove SP at the end of usage string From: Thiago Farina <tfransosi@xxxxxxxxx> These spaces immediately before the end of lines are unnecessary. While at it, instead of using a single string literal with backslashes at end of each line, split the lines into individual string literals and tell the compiler to concatenate them. Signed-off-by: Thiago Farina <tfransosi@xxxxxxxxx> --- builtin-pack-objects.c | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c index 7a390e1..02f9246 100644 --- a/builtin-pack-objects.c +++ b/builtin-pack-objects.c @@ -22,15 +22,15 @@ #include <pthread.h> #endif -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]"; +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]*]\n" + " [--reflog] [--stdout | base-name] [--include-tag]\n" + " [--keep-unreachable | --unpack-unreachable \n" + " [<ref-list | <object-list]"; struct object_entry { struct pack_idx_entry idx; -- 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