git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 18, 2009, 19:11 UTC
Message-ID
<7v1vm49ifb.fsf@alter.siamese.dyndns.org>
In-Reply-To
<a4c8a6d00909180802r713d7644mcb4e98ae4352a03a@mail.gmail.com>
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.

> 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.

Show 6 quoted lines
>> 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@gmail.com>
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@gmail.com>
---
 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;
Previous: Thiago FarinaNext: Thiago Farina
Message 6 of 7 in “Avoid the use of backslash-at-eol in pack-objects usage string.”
  1. Avoid the use of backslash-at-eol in pack-objects usage string.Thiago Farina, Sep 17, 2009
  2. Junio C HamanoSep 17, 2009
  3. Thiago FarinaSep 17, 2009
  4. Junio C HamanoSep 18, 2009
  5. Thiago FarinaSep 18, 2009
  6. Junio C HamanoSep 18, 2009
  7. Thiago FarinaSep 18, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.