* Re: [PATCH v2] builtin/branch.c: adjust error messages to coding guidelines
From: Rubén Justo @ 2023-10-21 10:27 UTC (permalink / raw)
To: Isoken June Ibizugbe, git; +Cc: christian.couder, gitster
In-Reply-To: <331e1ab3-2e8c-497d-a05d-ef197d664188@gmail.com>
On 19-oct-2023 21:20:24, Rubén Justo wrote:
> So, aside from the confusing message, this iteration looks good to me.
Reviewing again the messages in builtin/branch.c, if you finally
re-roll, maybe you want to add:
diff --git a/builtin/branch.c b/builtin/branch.c
index e7ee9bd0f1..31da889e95 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -777,7 +777,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (!strcmp(head, "HEAD"))
filter.detached = 1;
else if (!skip_prefix(head, "refs/heads/", &head))
- die(_("HEAD not found below refs/heads!"));
+ die(_("HEAD not found below refs/heads"));
But if you don't include this nit, that's fine with me. I still think
the changes you've already made are correct.
Thank you.
^ permalink raw reply related
* Re: Is there any interest in localizing term delimiters in git messages?
From: Peter Krefting @ 2023-10-21 9:30 UTC (permalink / raw)
To: Git List
In-Reply-To: <CAP6f5Mmi=f4DPcFwfvEiJMdKMa0BUyZ019mc8uFXyOufgD4NjA@mail.gmail.com>
Alexander Shopov:
> Hello all,
>
> Is there any interest in being able to change the delimiters of the
> changeable terms in git messages?
>
> Typical example:
> ORIGINAL
> msgid " (use \"git rm --cached <file>...\" to unstage)"
I think there should be something indicating the variables, and with
Unicode there are better choices than the ASCII
less-than-greater-than, for instance U+2039/U+203A. In the same way,
we could also fix the quotation marks:
" (use “git rm --cached ‹file›...” to unstage)"
The source should perhaps still be ASCII-only to be compatible with
older systems, but we could create a en_US.UTF-8 localization file
that does the above, and apply similar changes to other localizations
(I have been thinking about doing it to the Swedish translation for a
while, but so far have not come around to; of course quoting differs
from language to language, with different styles for ‘English’,
“American”, „German”, ”Swedish” and «Norwegian», for instance; it is
all very confusing and difficult to get right).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] typo: fix the typo 'neeed' into 'needed' in the comment under merge-ort.c
From: Bagas Sanjaya @ 2023-10-21 8:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: 王常新, git
In-Reply-To: <xmqqfs25rzo1.fsf@gitster.g>
On 21/10/2023 00:06, Junio C Hamano wrote:
> Bagas Sanjaya <bagasdotme@gmail.com> writes:
>
>> On 20/10/2023 09:14, 王常新 wrote:
>>> It is my official name. But the email address is not a valid one. Should I rewrite the commit message?
>>>
>>
>> Please don't top-post, reply inline with appropriate context instead.
>>
>> Did you mean that you can't receive ML traffic on your @qq.com address?
>> If so, resend with your @gmail.com address as patch author (you need
>> to set user.name and user.email accordingly).
>
> Isn't that opposite from what we would normally recommend, though?
>
> If the true authorship e-mail is in an environment where sending
> patches are inconvenient, you would still want to do your commits
> under the identity you want to appear in the final history of the
> project, so you do not futz with user.name and user.email; you'd
> send a message with in-body header that shows an extra From: line
> (followed by a blank line) that records the true authorship from an
> environment whose sender e-mail address may differ.
>
> E.g. You would see these fields in the e-mail heeader:
>
> From: 王常新 <wchangxin824@gmail.com>
> Subject: [PATCH] merge-ort.c: comment typofix
>
> and your message would begin like so (indented only for illustration
> purposes---the real one should be flushed to the left edge of the
> page):
>
> From: 王常新 <real-email-address-of-mr-wang@do.ma.in>
>
> There is 'needed' misspelt as 'neeed' in the source file;
> fix it.
>
> Signed-off-by: 王常新 <real-email-address-of-mr-wang@do.ma.in>
>
> This feature is designed so that other people, different from the
> author of the patch, can relay it to the recipient(s) while
> preserving the authorship information.
>
> Although it is not needed in this case, you can override "Subject:"
> the same way with an in-body header, like so:
>
> From: 王常新 <real-email-address-of-mr-wang@do.ma.in>
> Subject: real title of the patch to be used
>
> There is 'needed' misspelt as 'neeed' in the source file;
> fix it.
>
> Signed-off-by: 王常新 <real-email-address-of-mr-wang@do.ma.in>
>
> and it would replace what we read from the Subject: e-mail header.
Thanks for the explanation! I was confused then...
--
An old man doll... just what I always wanted! - Clara
^ permalink raw reply
* Re: [RESEND] git-rebase.txt: rewrite docu for fixup/squash (again)
From: Oswald Buddenhagen @ 2023-10-21 7:26 UTC (permalink / raw)
To: Marc Branchaud
Cc: git, Junio C Hamano, Phillip Wood, Christian Couder,
Charvi Mendiratta
In-Reply-To: <841c3b59-9e7c-4492-9d66-8af42c3222ea@xiplink.com>
On Fri, Oct 20, 2023 at 05:40:01PM -0400, Marc Branchaud wrote:
>I think the original text's "those identified by" is a bit vague: Does
>"those" mean "messages" or "commits"? The sentence reads like "those"
>stands for "messages", but then of course you don't identify *messages*
>with "squash" commands.
>
fair enough, though the repetition makes it linguistically inferior.
>Maybe emphasize the word "only" in the sentence (i.e. spell it as
>'only').
>
that seems excessive to me. i'm not assuming that my readers are dumb.
> To really drive the point home it could say something like
> obtained 'only' from the "fixup -c" commit, dropping the
> messages of all the other involved commits
>
as above.
also, i'm actually uneasy about including the exact behavior in the
first place, as it codifies something questionable - a better response
from git would be complaining about it. i will drop it.
>> (having more than one "fixup -c" commit
>> +makes no sense, and only the message from the last one is used).
>
>"Makes no sense" seems a bit opinionated (although I agree with the
>sentiment).
>
i'm not terribly worried about readers who have an aversion towards
being told facts ...
anyway, i will use "is incorrect" instead, as it seems more to the
point.
>Also, you can legitimately have more than one "fixup -c" in the overall
>instruction set, as long as there's at least one "pick" command in
>between, e.g.
>
yes, but the context is a single fixup sequence. the above comments
about readers and repetition apply here, too.
>[1] Makes me wonder if rebase should also support "squash -c"...
>
the distinction is that "squash" combines the messages, while "fixup"
discards them, and the -c merely changes what is discarded. softening
that up seems counter-productive to me.
thanks
^ permalink raw reply
* Re: [PATCH v4 1/4] hex-ll: separate out non-hash-algo functions
From: Linus Arver @ 2023-10-21 4:14 UTC (permalink / raw)
To: Jonathan Tan, git
Cc: Calvin Wan, phillip.wood123, Junio C Hamano, Jonathan Tan
In-Reply-To: <02ecc00e9c7226c9eeb960cc49c8c03dcb182a38.1696021277.git.jonathantanmy@google.com>
Jonathan Tan <jonathantanmy@google.com> writes:
> From: Calvin Wan <calvinwan@google.com>
>
> In order to further reduce all-in-one headers, separate out functions in
> hex.h that do not operate on object hashes into its own file, hex-ll.h,
Nit: I was wondering what the "-ll" in "hex-ll.h" meant, then found
d1cbe1e6d8 (hash-ll.h: split out of hash.h to remove dependency on
repository.h, 2023-04-22) which seems to have set the precedent for this
naming style. Might be worth including here.
^ permalink raw reply
* Re: [PATCH] typo: fix the typo 'neeed' into 'needed' in the comment under merge-ort.c
From: 王常新 @ 2023-10-21 1:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqv8b1s0pf.fsf@gitster.g>
> 2023年10月21日 00:44，Junio C Hamano <gitster@pobox.com> 写道：
>
> 王常新 <wchangxin824@gmail.com> writes:
>
>> It is my official name. But the email address is not a valid one. Should I rewrite the commit message?
>
> We try to keep the name and address on Signed-off-by: the official
> one that we can give court if/when some copyright troll sues us (see
> Documentation/SubmittingPatches:sign-off), and one of them (if more
> than one developers signed off the patch) must match the primary
> author's name and address.
>
> Thanks.
Sorry about that, I am not quite familiar with the process. I mean I can receive emails at both @qq.com and @gmail.com, but <foril@foril.space> in the signed-off-by trailer in the commit message doesn’t actually exist.
Given this situation, I am unsure of the next steps to correct this issue. Would it be appropriate for me to use 'rebase -i' to amend the erroneous commit message, followed by a force push to update the PR on GitHub? After this, is the correct following step to add another comment with "/submit" to finalize the changes?
Sincerely apologize for any inconvenience my mistake may have caused and appreciate your guidance on resolving this matter. Your patience and support in this learning process mean a lot to me.
^ permalink raw reply
* Re: [PATCH v3 1/1] bugreport: include +i in outfile suffix as needed
From: Junio C Hamano @ 2023-10-21 0:39 UTC (permalink / raw)
To: Jacob Stopak, Emily Shaffer; +Cc: git
In-Reply-To: <20231016214045.146862-2-jacob@initialcommit.io>
Jacob Stopak <jacob@initialcommit.io> writes:
> int cmd_bugreport(int argc, const char **argv, const char *prefix)
> {
> struct strbuf buffer = STRBUF_INIT;
> struct strbuf report_path = STRBUF_INIT;
> int report = -1;
> time_t now = time(NULL);
> - struct tm tm;
> enum diagnose_mode diagnose = DIAGNOSE_NONE;
> char *option_output = NULL;
> - char *option_suffix = "%Y-%m-%d-%H%M";
> + char *option_suffix = "";
> + int option_suffix_is_from_user = 0;
> const char *user_relative_path = NULL;
> char *prefixed_filename;
> - size_t output_path_len;
> int ret;
> + int i = 0;
OK, I think between me and you, we stared at this piece of code long
enough to make ourselves numb. The original "at most one report per
a minute" default came from the very original in 238b439d
(bugreport: add tool to generate debugging info, 2020-04-16) and
that is what we are changing, so let me summon its author as an area
expert for a pair of fresh eyes to see if they can offer any new
insights.
Thanks.
https://lore.kernel.org/git/20231016214045.146862-1-jacob@initialcommit.io/
^ permalink raw reply
* Re: [RESEND] git-rebase.txt: rewrite docu for fixup/squash (again)
From: Junio C Hamano @ 2023-10-21 0:22 UTC (permalink / raw)
To: Marc Branchaud
Cc: Oswald Buddenhagen, git, Phillip Wood, Christian Couder,
Charvi Mendiratta
In-Reply-To: <b5bc179d-46b6-4c48-bfe5-769dac38489b@xiplink.com>
Marc Branchaud <marcnarc@xiplink.com> writes:
> I should have added "as a convenience". Squash and fixup are similar
> enough that it seems reasonable for them to both support -c. Saves
> people from having to remember that only fixup allows -c.
Yeah, "fixup" could have been a plain "squash" with some option. It
could have been two options, "-i" ("ignore message of this one") and
"-o" ("use message of this one alone"), and then today's "fixup"
would have been "squash -i", and today's "fixup -c" would have been
"squash -o".
But I agree that "squash -c" is something one may find tempting to
type, after learning "fixup -c".
I forgot to comment on the real contents of your review, by the way.
Everything you said was reasonable.
^ permalink raw reply
* Re: [RESEND] git-rebase.txt: rewrite docu for fixup/squash (again)
From: Marc Branchaud @ 2023-10-20 23:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: Oswald Buddenhagen, git, Phillip Wood, Christian Couder,
Charvi Mendiratta
In-Reply-To: <xmqq1qdoq3tt.fsf@gitster.g>
On 2023-10-20 19:19, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> [1] Makes me wonder if rebase should also support "squash -c"...
>
> How would it be different from "fixup -c", though?
>
> A "pick" followed by either "fixup -c" or "squash -c" will have the
> same effect on the contents (i.e., apply the changes both commits
> want to make to their respective parents) and present the end user
> an editor buffer filled with the commit specified by the "-c"
> option, right?
>
> Or am I missing something?
No, you're not.
I should have added "as a convenience". Squash and fixup are similar
enough that it seems reasonable for them to both support -c. Saves
people from having to remember that only fixup allows -c.
M.
^ permalink raw reply
* Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
From: Junio C Hamano @ 2023-10-20 23:28 UTC (permalink / raw)
To: Dragan Simic; +Cc: Jacob Stopak, git
In-Reply-To: <d3bbe53c3b910f891c80465ea0c3f53f@manjaro.org>
Dragan Simic <dsimic@manjaro.org> writes:
> Please don't get me wrong, I understand your reasoning, but again, it
> all comes down to the two categories described above. IMHO, the
> second category will likely start turning off the default hints sooner
> than turning the table formatting on. The first category will choose
> some GUI anyway.
You are not alone in feeling the impedance mismatch between the
intended audience the patch(es) try to help (pointy-clicky GUI
users) and the codebase the patch(es) modify (perhaps spartan
command line interface). I did wonder why this is not made as a
part of sugarcoating the command line interface with some GUI that
shows what could be added, what has been added, and the stuff in its
"git status" equivalent.
^ permalink raw reply
* Re: [RESEND] git-rebase.txt: rewrite docu for fixup/squash (again)
From: Junio C Hamano @ 2023-10-20 23:19 UTC (permalink / raw)
To: Marc Branchaud
Cc: Oswald Buddenhagen, git, Phillip Wood, Christian Couder,
Charvi Mendiratta
In-Reply-To: <841c3b59-9e7c-4492-9d66-8af42c3222ea@xiplink.com>
Marc Branchaud <marcnarc@xiplink.com> writes:
> [1] Makes me wonder if rebase should also support "squash -c"...
How would it be different from "fixup -c", though?
A "pick" followed by either "fixup -c" or "squash -c" will have the
same effect on the contents (i.e., apply the changes both commits
want to make to their respective parents) and present the end user
an editor buffer filled with the commit specified by the "-c"
option, right?
Or am I missing something?
^ permalink raw reply
* Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
From: Dragan Simic @ 2023-10-20 23:02 UTC (permalink / raw)
To: Jacob Stopak; +Cc: git
In-Reply-To: <ZTL1wJIIK/5YWQK5.jacob@initialcommit.io>
On 2023-10-20 23:48, Jacob Stopak wrote:
> On Fri, Oct 20, 2023 at 08:48:12PM +0200, Dragan Simic wrote:
>> On 2023-10-20 20:39, Jacob Stopak wrote:
>> > This is a proposal / proof-of-concept for a new table-based output
>> > format for the git status command, and for dry runs (-n) of the git add
>> > command. This could be extended to create visual dry runs for other
>> > other commands like rm, mv, restore, stash, commit, and clean.
>>
>> Huh, please don't get me wrong, but based on the examples provided
>> below, I
>> really think that's only wasted screen estate, providing little or no
>> help
>> in understanding the performed operations.
>>
>> I appreciate your effort, but IMHO it makes little sense from the
>> usability
>> standpoint.
>>
> Thanks for the quick (and honest ;) reply - I appreciate it and no
> offense
> taken! But let me try to expand on my reasoning a bit.
Thank you!
> I agree with you that Git users who are already comfortable with Git,
> the command-line, and their workflows would be unlikely to use this in
> their day to day work.
>
> The main benefits of this format are for beginners and folks who
> are still learning Git to use it as needed:
Oh, I always do my best to put myself in the shoes of the targeted
audience. Maybe I sometimes fail at that, I don't know, but that's why
we're here to discuss it further.
> * To beginners, the concepts of working directory and "staging area"
> can be very abstract. By representing these concepts as table
> columns
> on the screen, (a format that 99% of humans are used to
> interpreting),
> they become more tangible and intuitive to new users.
Frankly, based on my rather broad experience, there are two primary
categories of the beginners in the world of version control software
(VCS), be it git or any other product:
1) People who are forced to use some VCS at work, and they actually
don't give a damn about it.
2) True enthusiasts who love what they do, and who love expanding their
knowledge.
For the first category, nothing helps. For the second category, a
nicely written tutorial is all they needed to start with, aided later
with the man pages, Stack Exchange, and perhaps some textbook.
> * In Git, changes fly around all over the place, in all sorts of
> directions. Even small hints at this movement can be very helpful
> to
> understand what the heck is going on. The table format (esp with
> arrows used in the 'git add' version) highlights the "flow" of
> changes through the workflow in a way that the current default
> format
> doesn't. The current dry runs just show the filenames being added
> without context of _where_ they come from and where they are going.
> Not to mention many commands don't even have dry runs. This might
> sound like a small thing, but to a newbie having that extra level
> of
> confirmation and understanding can make a big difference.
Please don't get me wrong, I understand your reasoning, but again, it
all comes down to the two categories described above. IMHO, the second
category will likely start turning off the default hints sooner than
turning the table formatting on. The first category will choose some
GUI anyway.
> * Git doesn't exactly have a reputation as a user-friendly tool, and
> much of that stems from the difficulty of learning Git. So we
> should
> try to make it more approachable to normal humans. This format
> (esp if applied to a wide variety of commands as dry runs) would
> provide a rudimentary visual output that is more intuitive to
> users.
No pain, no gain. That's the ancient mantra, but IMHO it still applies
very well to many things, and of course not to the first category
mentioned above. Nothing applies to that category.
> * This flag doesn't change any default behavior, it can easily be
> tossed on for newbie use (either when teaching a newbie or when the
> newbie is practicing on their own). Given this usage, the screen
> realestate is not really a concern. I.e. this would be used
> specifically when needed for the extra info/clarity it provides,
> not to be efficient with the terminal space.
As I already assumed above, the targeted audience will likely start
turning the default hints off, rather than turning the table formatting
on. Maybe I'm wrong there, who knows.
> That's my perspective anyway, but of course the point of this is to
> propose it to the community and hear the response, so even if it's
> not included it's still a good experience :D.
Let's hear more thoughts from other people, of course.
^ permalink raw reply
* Re: [PATCH v3 0/3] rebase refactoring
From: Junio C Hamano @ 2023-10-20 22:07 UTC (permalink / raw)
To: Oswald Buddenhagen; +Cc: git
In-Reply-To: <20231020093654.922890-1-oswald.buddenhagen@gmx.de>
Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:
> broken out of the bigger series, as the aggregation just unnecessarily holds it
> up.
>
> v3: removed "stray" footer. so more of a RESEND than an actual new version.
>
> Oswald Buddenhagen (3):
> rebase: simplify code related to imply_merge()
> rebase: handle --strategy via imply_merge() as well
> rebase: move parse_opt_keep_empty() down
>
> builtin/rebase.c | 44 ++++++++++++++------------------------------
> 1 file changed, 14 insertions(+), 30 deletions(-)
Looking quite straight-forward and I didn't see anythihng
potentially controversial.
Will queue. Thanks.
^ permalink raw reply
* Re: [PATCH v3 2/3] rebase: handle --strategy via imply_merge() as well
From: Junio C Hamano @ 2023-10-20 21:51 UTC (permalink / raw)
To: Oswald Buddenhagen; +Cc: git, Phillip Wood
In-Reply-To: <20231020093654.922890-3-oswald.buddenhagen@gmx.de>
Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:
> At least after the successive trimming of enum rebase_type mentioned in
> the previous commit, this code did exactly what imply_merge() does, so
> just call it instead.
>
> Suggested-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Hmph, I do not recall suggesting it, but the resulting code does
make sense. ;-)
>
> ---
> Cc: Phillip Wood <phillip.wood123@gmail.com>
> ---
> builtin/rebase.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/builtin/rebase.c b/builtin/rebase.c
> index 44cc1eed12..4a093bb125 100644
> --- a/builtin/rebase.c
> +++ b/builtin/rebase.c
> @@ -1490,18 +1490,7 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
>
> if (options.strategy) {
> options.strategy = xstrdup(options.strategy);
> - switch (options.type) {
> - case REBASE_APPLY:
> - die(_("--strategy requires --merge or --interactive"));
> - case REBASE_MERGE:
> - /* compatible */
> - break;
> - case REBASE_UNSPECIFIED:
> - options.type = REBASE_MERGE;
> - break;
> - default:
> - BUG("unhandled rebase type (%d)", options.type);
> - }
> + imply_merge(&options, "--strategy");
> }
>
> if (options.root && !options.onto_name)
^ permalink raw reply
* Re: [RFC PATCH 0/5] Introduce -t, --table for status/add commands
From: Jacob Stopak @ 2023-10-20 21:48 UTC (permalink / raw)
To: Dragan Simic; +Cc: git
In-Reply-To: <fd26df85661d554ced9d8e0445f75952@manjaro.org>
On Fri, Oct 20, 2023 at 08:48:12PM +0200, Dragan Simic wrote:
> On 2023-10-20 20:39, Jacob Stopak wrote:
> > This is a proposal / proof-of-concept for a new table-based output
> > format for the git status command, and for dry runs (-n) of the git add
> > command. This could be extended to create visual dry runs for other
> > other commands like rm, mv, restore, stash, commit, and clean.
>
> Huh, please don't get me wrong, but based on the examples provided below, I
> really think that's only wasted screen estate, providing little or no help
> in understanding the performed operations.
>
> I appreciate your effort, but IMHO it makes little sense from the usability
> standpoint.
>
Thanks for the quick (and honest ;) reply - I appreciate it and no offense
taken! But let me try to expand on my reasoning a bit.
I agree with you that Git users who are already comfortable with Git,
the command-line, and their workflows would be unlikely to use this in
their day to day work.
The main benefits of this format are for beginners and folks who
are still learning Git to use it as needed:
* To beginners, the concepts of working directory and "staging area"
can be very abstract. By representing these concepts as table columns
on the screen, (a format that 99% of humans are used to interpreting),
they become more tangible and intuitive to new users.
* In Git, changes fly around all over the place, in all sorts of
directions. Even small hints at this movement can be very helpful to
understand what the heck is going on. The table format (esp with
arrows used in the 'git add' version) highlights the "flow" of
changes through the workflow in a way that the current default format
doesn't. The current dry runs just show the filenames being added
without context of _where_ they come from and where they are going.
Not to mention many commands don't even have dry runs. This might
sound like a small thing, but to a newbie having that extra level of
confirmation and understanding can make a big difference.
* Git doesn't exactly have a reputation as a user-friendly tool, and
much of that stems from the difficulty of learning Git. So we should
try to make it more approachable to normal humans. This format
(esp if applied to a wide variety of commands as dry runs) would
provide a rudimentary visual output that is more intuitive to users.
* This flag doesn't change any default behavior, it can easily be
tossed on for newbie use (either when teaching a newbie or when the
newbie is practicing on their own). Given this usage, the screen
realestate is not really a concern. I.e. this would be used
specifically when needed for the extra info/clarity it provides,
not to be efficient with the terminal space.
That's my perspective anyway, but of course the point of this is to
propose it to the community and hear the response, so even if it's
not included it's still a good experience :D.
^ permalink raw reply
* Re: [PATCH 2/3] Revert "send-email: extract email-parsing code into a subroutine"
From: Junio C Hamano @ 2023-10-20 21:45 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Strawbridge, Bagas Sanjaya, Git Mailing List
In-Reply-To: <20231020101310.GB2673716@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> - the handling for to/cc/bcc is totally broken.
It is good to see another evidence that "--compose" is probably not
as often as used as we thought. With enough bugs discovered,
perhaps someday we can declare "it cannot be that the feature is
used in the wild, without anybody getting hit by these bugs---let's
deprecate and eventually remove it" ;-)
^ permalink raw reply
* Re: [PATCH 0/3] some send-email --compose fixes
From: Junio C Hamano @ 2023-10-20 21:42 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Strawbridge, Bagas Sanjaya, Git Mailing List
In-Reply-To: <20231020100343.GA2194322@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> [culling the rather large cc, as we moving off the original topic]
>
> On Fri, Oct 20, 2023 at 03:14:03AM -0400, Jeff King wrote:
>
>> and there's your perl array ref (from the square brackets, which are
>> necessary because we're sticking it in a hash value). But even before
>> your patch, this seems to end up as garbage. The code which reads
>> $parsed_line does not dereference the array.
>>
>> The patch to fix it is only a few lines (well, more than that with some
>> light editorializing in the comments):
>
> So here's the fix in a cleaned up form, guided by my own comments from
> earlier. ;) I think this is actually all orthogonal to the patch you are
> working on, so yours could either go on top or just be applied
> separately.
>
> [1/3]: doc/send-email: mention handling of "reply-to" with --compose
> [2/3]: Revert "send-email: extract email-parsing code into a subroutine"
> [3/3]: send-email: handle to/cc/bcc from --compose message
Nice.
With the approach suggested to move the validation down to where the
necessary addresses are already all defined, Michael observed "whoa,
why am I getting stringified array ref?". If that is the only issue
in the approach, queuing these three patches first and then have
Michael's fix on top of them sounds like the cleanest thing to do.
Will queue on top of v2.42.0 to help those who may want to backport
these to the maintenance track.
Thanks.
^ permalink raw reply
* Re: [RESEND] git-rebase.txt: rewrite docu for fixup/squash (again)
From: Marc Branchaud @ 2023-10-20 21:40 UTC (permalink / raw)
To: Oswald Buddenhagen, git
Cc: Junio C Hamano, Phillip Wood, Christian Couder, Charvi Mendiratta
In-Reply-To: <20231020092707.917514-1-oswald.buddenhagen@gmx.de>
On 2023-10-20 05:27, Oswald Buddenhagen wrote:
> Create a clear top-down structure which makes it hopefully unambiguous
> what happens when.
>
> Also mention the timestamp along with the author - this is primarily
> meant to include the keywords somebody might be searching for, like I
> did a year ago.
>
> Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
I think this is a definite improvement to the text. Thanks for working
on this! I do have a few suggestions, below.
> ---
> Cc: Junio C Hamano <gitster@pobox.com>
> Cc: Phillip Wood <phillip.wood123@gmail.com>
> Cc: Christian Couder <christian.couder@gmail.com>
> Cc: Charvi Mendiratta <charvi077@gmail.com>
> Cc: Marc Branchaud <marcnarc@xiplink.com>
> ---
> Documentation/git-rebase.txt | 29 +++++++++++++++--------------
> 1 file changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index e7b39ad244..857e025361 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -890,20 +890,21 @@ command "pick" with the command "reword".
> To drop a commit, replace the command "pick" with "drop", or just
> delete the matching line.
>
> -If you want to fold two or more commits into one, replace the command
> -"pick" for the second and subsequent commits with "squash" or "fixup".
> -If the commits had different authors, the folded commit will be
> -attributed to the author of the first commit. The suggested commit
> -message for the folded commit is the concatenation of the first
> -commit's message with those identified by "squash" commands, omitting the
> -messages of commits identified by "fixup" commands, unless "fixup -c"
> -is used. In that case the suggested commit message is only the message
> -of the "fixup -c" commit, and an editor is opened allowing you to edit
> -the message. The contents (patch) of the "fixup -c" commit are still
> -incorporated into the folded commit. If there is more than one "fixup -c"
> -commit, the message from the final one is used. You can also use
> -"fixup -C" to get the same behavior as "fixup -c" except without opening
> -an editor.
> +If you want to fold two or more commits into one (that is, to combine
> +their contents/patches), replace the command "pick" for the second and
> +subsequent commits with "squash" or "fixup".
> +The commit message for the folded commit is the concatenation of the
> +first commit's message with those identified by "squash" commands,
I think the original text's "those identified by" is a bit vague: Does
"those" mean "messages" or "commits"? The sentence reads like "those"
stands for "messages", but then of course you don't identify *messages*
with "squash" commands.
Maybe
those from commits identified by
?
> +omitting the messages of commits identified by "fixup" commands, unless
> +"fixup -c" is used. In the latter case, the message is obtained only
> +from the "fixup -c" commit
I think it's worth emphasizing that "fixup -c" also drops the message
from the initial "pick" commit as well as all the "squash" commits (I
presume that's the case, I haven't tried it [1]).
Maybe emphasize the word "only" in the sentence (i.e. spell it as
'only'). To really drive the point home it could say something like
obtained 'only' from the "fixup -c" commit, dropping the
messages of all the other involved commits
> (having more than one "fixup -c" commit
> +makes no sense, and only the message from the last one is used).
"Makes no sense" seems a bit opinionated (although I agree with the
sentiment). Also, you can legitimately have more than one "fixup -c" in
the overall instruction set, as long as there's at least one "pick"
command in between, e.g.
pick 1111beef
fixup 2222f00d
fixup -c 3333ab1e
pick 4444d00d
fixup 5555feed
fixup -c 6666dead
How about
(if more than one "fixup -c" command appears in a sequence
of "fixup" and "squash" commands, only the message from
the last "fixup -c" commit is used)
Thanks,
M.
[1] Makes me wonder if rebase should also support "squash -c"...
^ permalink raw reply
* Re: [PATCH v5 2/3] trailer: find the end of the log message
From: Junio C Hamano @ 2023-10-20 21:29 UTC (permalink / raw)
To: Linus Arver via GitGitGadget
Cc: git, Glen Choo, Christian Couder, Phillip Wood, Jonathan Tan,
Linus Arver
In-Reply-To: <ce25420db29c9953095db652584dbed4e35d67ad.1697828495.git.gitgitgadget@gmail.com>
"Linus Arver via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Linus Arver <linusa@google.com>
>
> Previously, trailer_info_get() computed the trailer block end position
> by
>
> (1) checking for the opts->no_divider flag and optionally calling
> find_patch_start() to find the "patch start" location (patch_start), and
> (2) calling find_trailer_end() to find the end of the trailer block
> using patch_start as a guide, saving the return value into
> "trailer_end".
>
> The logic in (1) was awkward because the variable "patch_start" is
> misleading if there is no patch in the input. The logic in (2) was
> misleading because it could be the case that no trailers are in the
> input (yet we are setting a "trailer_end" variable before even searching
> for trailers, which happens later in find_trailer_start()). The name
> "find_trailer_end" was misleading because that function did not look for
> any trailer block itself --- instead it just computed the end position
> of the log message in the input where the end of the trailer block (if
> it exists) would be (because trailer blocks must always come after the
> end of the log message).
>
> Combine the logic in (1) and (2) together into find_patch_start() by
> renaming it to find_end_of_log_message(). The end of the log message is
> the starting point which find_trailer_start() needs to start searching
> backward to parse individual trailers (if any).
>
> Helped-by: Jonathan Tan <jonathantanmy@google.com>
> Helped-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Linus Arver <linusa@google.com>
> ---
> trailer.c | 64 +++++++++++++++++++++++++++++++++++--------------------
> 1 file changed, 41 insertions(+), 23 deletions(-)
>
> diff --git a/trailer.c b/trailer.c
> index 3c54b38a85a..70c81fda710 100644
> --- a/trailer.c
> +++ b/trailer.c
> @@ -809,21 +809,50 @@ static ssize_t last_line(const char *buf, size_t len)
> }
>
> /*
> - * Return the position of the start of the patch or the length of str if there
> - * is no patch in the message.
> + * Find the end of the log message as an offset from the start of the input
> + * (where callers of this function are interested in looking for a trailers
> + * block in the same input). We have to consider two categories of content that
> + * can come at the end of the input which we want to ignore (because they don't
> + * belong in the log message):
> + *
> + * (1) the "patch part" which begins with a "---" divider and has patch
> + * information (like the output of git-format-patch), and
> + *
> + * (2) any trailing comment lines, blank lines like in the output of "git
> + * commit -v", or stuff below the "cut" (scissor) line.
> + *
> + * As a formula, the situation looks like this:
> + *
> + * INPUT = LOG MESSAGE + IGNORED
> + *
> + * where IGNORED can be either of the two categories described above. It may be
> + * that there is nothing to ignore. Now it may be the case that the LOG MESSAGE
> + * contains a trailer block, but that's not the concern of this function.
> */
> -static size_t find_patch_start(const char *str)
> +static size_t find_end_of_log_message(const char *input, int no_divider)
> {
> + size_t end;
> const char *s;
>
> - for (s = str; *s; s = next_line(s)) {
> + /* Assume the naive end of the input is already what we want. */
> + end = strlen(input);
> +
> + if (no_divider) {
> + return end;
> + }
OK. The early return may make sense, as we are essentially
declaring that everything is the "INPUT (= message + ignored)".
You do not need {braces} around a single-statement block, though.
Other than that, I didn't find anything quesionable in any of the
patches in this round. Looking good.
Thanks.
^ permalink raw reply
* Re: Regression: git send-email fails with "Use of uninitialized value $address" + "unable to extract a valid address"
From: Michael Strawbridge @ 2023-10-20 21:06 UTC (permalink / raw)
To: Uwe Kleine-König, git; +Cc: Luben Tuikov, entwicklung
In-Reply-To: <20231020100442.an47wwsti2d4zeyx@pengutronix.de>
On 10/20/23 06:04, Uwe Kleine-König wrote:
> hello,
>
> On Fri, Oct 13, 2023 at 04:14:37PM +0200, Uwe Kleine-König wrote:
>> Hello,
>>
>> $ git send-email --to 'A B <a@b.org>, C D <c@d.org>' lala.patch
>> Use of uninitialized value $address in sprintf at /usr/lib/git-core/git-send-email line 1172.
>> error: unable to extract a valid address from:
>>
>> This happens for me with git 2.42.0 and also on master (59167d7d09fd, "The seventeenth batch").
>>
>> Bisection points at
>>
>> a8022c5f7b67 ("send-email: expose header information to git-send-email's sendemail-validate hook")
>>
>> I didn't try to understand that change and fix the problem.
>
> Another (similar?) problem with non-ascii-chars:
>
> $ git send-email --to 'Will Deacon <will@kernel.org>' --to 'Krzysztof Wilczyński <kw@linux.com>' --to 'Lorenzo Pieralisi <lpieralisi@kernel.org>' --cc 'Rob Herring <robh@kernel.org>' --to 'Bjorn Helgaas <bhelgaas@google.com>' --cc 'linux-pci@vger.kernel.org' --cc kernel@pengutronix.de -1 --base=@~
> Use of uninitialized value $address in sprintf at /home/uwe/gsrc/git/git-send-email line 1162.
> error: unable to extract a valid address from:
>
> Bisection points to the same commit, when dropping ń in Krzysztof's
> name, it works fine.
>
This is interesting. Thanks for reporting it. If you are able, could you please try the patches found in the below threads:
- https://public-inbox.org/git/20230918212004.GC2163162@coredump.intra.peff.net/T/#mae64003cbb72f015bf5c0c04216524fcb6bb8d09
- https://public-inbox.org/git/f5c6a72b-f888-4d43-8be8-3ce2c878c669@gmail.com/T/#mca12dc95ccfd3ce2b94e7752ebaae9891201084f
Thanks,
Michael
> Best regards
> Uwe
>
^ permalink raw reply
* Re: [PATCH] git-push: more visibility for -q option
From: Junio C Hamano @ 2023-10-20 20:08 UTC (permalink / raw)
To: Michal Suchanek; +Cc: git
In-Reply-To: <20231020184627.14336-1-msuchanek@suse.de>
Michal Suchanek <msuchanek@suse.de> writes:
> The -v option listed at the top as option al parameter while -q is not.
"as option al parameter" - ECANNOTPARSE. Probably
The `-v` option is shown in the SYNOPSIS section near the top,
but `-q` is not shown anywhere there.
or something, I think. I agree showing it next to "-v" would make
the most sense.
>
> List -q alongside -v.
>
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> ---
> Documentation/git-push.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 5b4edaf4a8..003bc7d9ce 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -10,7 +10,7 @@ SYNOPSIS
> --------
> [verse]
> 'git push' [--all | --branches | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
> - [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-v | --verbose]
> + [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-q | --quiet] [-v | --verbose]
Yup, the change makes sense. We may want to wrap the first line to
a more reasonable length in a separate commit, and when that
happens, we probably would want to start [-v] [-q] on a separate
line as well, but for now this would do.
^ permalink raw reply
* Re: [PATCH] git-push: more visibility for -q option
From: Eric Sunshine @ 2023-10-20 20:05 UTC (permalink / raw)
To: Michal Suchanek; +Cc: git
In-Reply-To: <20231020184627.14336-1-msuchanek@suse.de>
On Fri, Oct 20, 2023 at 2:46 PM Michal Suchanek <msuchanek@suse.de> wrote:
> The -v option listed at the top as option al parameter while -q is not.
s/option al/optional/
> List -q alongside -v.
>
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
^ permalink raw reply
* Re: [PATCH 05/11] t: convert tests to not access symrefs via the filesystem
From: Junio C Hamano @ 2023-10-20 19:52 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Han-Wen Nienhuys
In-Reply-To: <1ac120368c6cd995841c28bde7542e882ec7b04f.1697607222.git.ps@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> @@ -164,9 +164,9 @@ test_expect_success 'rev-parse skips symref pointing to broken name' '
> test_expect_success 'for-each-ref emits warnings for broken names' '
> test-tool ref-store main update-ref msg "refs/heads/broken...ref" $main_sha1 $ZERO_OID REF_SKIP_REFNAME_VERIFICATION &&
> test_when_finished "test-tool ref-store main delete-refs REF_NO_DEREF msg refs/heads/broken...ref" &&
> - printf "ref: refs/heads/broken...ref\n" >.git/refs/heads/badname &&
> + test-tool ref-store main create-symref refs/heads/badname refs/heads/broken...ref &&
I am of two minds here. While it certainly smells nicer because we
can test ref backends other than the files backend with this change,
we are forcing all ref backends to support creating a symbolic ref
with invalid name, because otherwise "test-tool" would not be able
to do this. Newer more database-oriented ref backends should be
allowed to implement their file format in which it is imposssible to
store such a bad name, but this makes it impossible.
I guess it is OK, because we would introduce some new prerequisite
(i.e. REF_BACKEND_ALLOWS_BROKEN_REFS) to skip this test on certain
ref backend where making invalid refs is impossible.
Other kind of changes in this patch, e.g., ...
> @@ -315,7 +325,9 @@ test_expect_success 'defaulted HEAD uses remote branch if available' '
> git -c init.defaultBranch=branchwithstuff -c protocol.version=2 \
> clone "file://$(pwd)/file_unborn_parent" \
> file_unborn_child 2>stderr &&
> - grep "refs/heads/branchwithstuff" file_unborn_child/.git/HEAD &&
> + echo "refs/heads/branchwithstuff" >expect &&
> + git -C file_unborn_child symbolic-ref HEAD >actual &&
> + test_cmp expect actual &&
> test_path_is_file file_unborn_child/stuff.t &&
> ! grep "warning:" stderr
> '
> diff --git a/t/t9133-git-svn-nested-git-repo.sh b/t/t9133-git-svn-nested-git-repo.sh
> index d8d536269cf..8ca24670acb 100755
> --- a/t/t9133-git-svn-nested-git-repo.sh
> +++ b/t/t9133-git-svn-nested-git-repo.sh
> @@ -11,7 +11,7 @@ test_expect_success 'setup repo with a git repo inside it' '
> (
> cd s &&
> git init &&
> - test -f .git/HEAD &&
> + git symbolic-ref HEAD &&
> > .git/a &&
> echo a > a &&
> svn_cmd add .git a &&
... all looked sensible, though.
Thanks.
^ permalink raw reply
* Why sometimes branch merging is associated with this commit: Merge remote-tracking branch 'remotes/p4/HEAD'
From: Yuri @ 2023-10-20 19:46 UTC (permalink / raw)
To: Git Mailing List
I use git-p4 to use the perforce repository through git.
There are 3 branches:
* master
remotes/p4/HEAD -> p4/master
remotes/p4/master
git-p4 syncs remotes/p4/HEAD with the perforce repository.
Then the user (me) needs to merge remotes/p4/HEAD into master.
Initially such merge doesn't cause "Merge remote-tracking branch
'remotes/p4/HEAD'" commits.
But then, after several cycles of submit/sync something happens, and git
forces me to commit with the "Merge remote-tracking branch
'remotes/p4/HEAD'" comment.
What makes the merge from remotes/p4/HEAD into master to require "Merge
remote-tracking branch 'remotes/p4/HEAD'"?
What does this mean?
What is changed in remotes/p4/HEAD or master that later requires this?
How to eliminate the need for "Merge remote-tracking branch
'remotes/p4/HEAD'"?
Thanks,
Yuri
^ permalink raw reply
* [PATCH v5 3/3] trailer: use offsets for trailer_start/trailer_end
From: Linus Arver via GitGitGadget @ 2023-10-20 19:01 UTC (permalink / raw)
To: git
Cc: Glen Choo, Christian Couder, Phillip Wood, Jonathan Tan,
Linus Arver, Linus Arver
In-Reply-To: <pull.1563.v5.git.1697828495.gitgitgadget@gmail.com>
From: Linus Arver <linusa@google.com>
Previously these fields in the trailer_info struct were of type "const
char *" and pointed to positions in the input string directly (to the
start and end positions of the trailer block).
Use offsets to make the intended usage less ambiguous. We only need to
reference the input string in format_trailer_info(), so update that
function to take a pointer to the input.
While we're at it, rename trailer_start to trailer_block_start to be
more explicit about these offsets (that they are for the entire trailer
block including other trailers). Ditto for trailer_end.
Reported-by: Glen Choo <glencbz@gmail.com>
Signed-off-by: Linus Arver <linusa@google.com>
---
sequencer.c | 2 +-
trailer.c | 29 ++++++++++++++---------------
trailer.h | 10 +++++-----
3 files changed, 20 insertions(+), 21 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index d584cac8ed9..8707a92204f 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -345,7 +345,7 @@ static int has_conforming_footer(struct strbuf *sb, struct strbuf *sob,
if (ignore_footer)
sb->buf[sb->len - ignore_footer] = saved_char;
- if (info.trailer_start == info.trailer_end)
+ if (info.trailer_block_start == info.trailer_block_end)
return 0;
for (i = 0; i < info.trailer_nr; i++)
diff --git a/trailer.c b/trailer.c
index 70c81fda710..f7dc7c4c008 100644
--- a/trailer.c
+++ b/trailer.c
@@ -859,7 +859,7 @@ static size_t find_end_of_log_message(const char *input, int no_divider)
* Return the position of the first trailer line or len if there are no
* trailers.
*/
-static size_t find_trailer_start(const char *buf, size_t len)
+static size_t find_trailer_block_start(const char *buf, size_t len)
{
const char *s;
ssize_t end_of_title, l;
@@ -1075,7 +1075,6 @@ void process_trailers(const char *file,
LIST_HEAD(head);
struct strbuf sb = STRBUF_INIT;
struct trailer_info info;
- size_t trailer_end;
FILE *outfile = stdout;
ensure_configured();
@@ -1086,11 +1085,10 @@ void process_trailers(const char *file,
outfile = create_in_place_tempfile(file);
parse_trailers(&info, sb.buf, &head, opts);
- trailer_end = info.trailer_end - sb.buf;
/* Print the lines before the trailers */
if (!opts->only_trailers)
- fwrite(sb.buf, 1, info.trailer_start - sb.buf, outfile);
+ fwrite(sb.buf, 1, info.trailer_block_start, outfile);
if (!opts->only_trailers && !info.blank_line_before_trailer)
fprintf(outfile, "\n");
@@ -1112,7 +1110,7 @@ void process_trailers(const char *file,
/* Print the lines after the trailers as is */
if (!opts->only_trailers)
- fwrite(sb.buf + trailer_end, 1, sb.len - trailer_end, outfile);
+ fwrite(sb.buf + info.trailer_block_end, 1, sb.len - info.trailer_block_end, outfile);
if (opts->in_place)
if (rename_tempfile(&trailers_tempfile, file))
@@ -1124,7 +1122,7 @@ void process_trailers(const char *file,
void trailer_info_get(struct trailer_info *info, const char *str,
const struct process_trailer_options *opts)
{
- int end_of_log_message, trailer_start;
+ size_t end_of_log_message = 0, trailer_block_start = 0;
struct strbuf **trailer_lines, **ptr;
char **trailer_strings = NULL;
size_t nr = 0, alloc = 0;
@@ -1133,10 +1131,10 @@ void trailer_info_get(struct trailer_info *info, const char *str,
ensure_configured();
end_of_log_message = find_end_of_log_message(str, opts->no_divider);
- trailer_start = find_trailer_start(str, end_of_log_message);
+ trailer_block_start = find_trailer_block_start(str, end_of_log_message);
- trailer_lines = strbuf_split_buf(str + trailer_start,
- end_of_log_message - trailer_start,
+ trailer_lines = strbuf_split_buf(str + trailer_block_start,
+ end_of_log_message - trailer_block_start,
'\n',
0);
for (ptr = trailer_lines; *ptr; ptr++) {
@@ -1157,9 +1155,9 @@ void trailer_info_get(struct trailer_info *info, const char *str,
strbuf_list_free(trailer_lines);
info->blank_line_before_trailer = ends_with_blank_line(str,
- trailer_start);
- info->trailer_start = str + trailer_start;
- info->trailer_end = str + end_of_log_message;
+ trailer_block_start);
+ info->trailer_block_start = trailer_block_start;
+ info->trailer_block_end = end_of_log_message;
info->trailers = trailer_strings;
info->trailer_nr = nr;
}
@@ -1174,6 +1172,7 @@ void trailer_info_release(struct trailer_info *info)
static void format_trailer_info(struct strbuf *out,
const struct trailer_info *info,
+ const char *msg,
const struct process_trailer_options *opts)
{
size_t origlen = out->len;
@@ -1183,8 +1182,8 @@ static void format_trailer_info(struct strbuf *out,
if (!opts->only_trailers && !opts->unfold && !opts->filter &&
!opts->separator && !opts->key_only && !opts->value_only &&
!opts->key_value_separator) {
- strbuf_add(out, info->trailer_start,
- info->trailer_end - info->trailer_start);
+ strbuf_add(out, msg + info->trailer_block_start,
+ info->trailer_block_end - info->trailer_block_start);
return;
}
@@ -1238,7 +1237,7 @@ void format_trailers_from_commit(struct strbuf *out, const char *msg,
struct trailer_info info;
trailer_info_get(&info, msg, opts);
- format_trailer_info(out, &info, opts);
+ format_trailer_info(out, &info, msg, opts);
trailer_info_release(&info);
}
diff --git a/trailer.h b/trailer.h
index ab2cd017567..1644cd05f60 100644
--- a/trailer.h
+++ b/trailer.h
@@ -32,16 +32,16 @@ int trailer_set_if_missing(enum trailer_if_missing *item, const char *value);
struct trailer_info {
/*
* True if there is a blank line before the location pointed to by
- * trailer_start.
+ * trailer_block_start.
*/
int blank_line_before_trailer;
/*
- * Pointers to the start and end of the trailer block found. If there
- * is no trailer block found, these 2 pointers point to the end of the
- * input string.
+ * Offsets to the trailer block start and end positions in the input
+ * string. If no trailer block is found, these are both set to the
+ * "true" end of the input (find_end_of_log_message()).
*/
- const char *trailer_start, *trailer_end;
+ size_t trailer_block_start, trailer_block_end;
/*
* Array of trailers found.
--
gitgitgadget
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox