From: Stefan Beller <sbeller@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>,
Christian Couder <chriscool@tuxfamily.org>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [RFC/PATCH 16/17] diff: buffer output in emit_line_0
Date: Tue, 13 Sep 2016 16:42:47 -0700 [thread overview]
Message-ID: <CAGZ79kaFofpU0TMd1ZcJa9UrzdFytg9UjqqtPf8WPXe0zjWihA@mail.gmail.com> (raw)
In-Reply-To: <xmqq60pztlz2.fsf@gitster.mtv.corp.google.com>
On Tue, Sep 13, 2016 at 4:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> So would we rather want to keep the ecbdata around for each file pair and
>> just reference that? I thought we deliberately want to avoid ecbdata, so maybe
>> we rather want to have another struct that keeps path related information
>> around (pointer to the blob and white space information).
>
> I would expect that there would be two structs, one per path
> "struct buffered_patch" that has the per-path thing, and another per
> line "struct buffered_patch_line" that describes what each line is,
> and has a pointer to the former.
>
Heh, I was trying to come up with a clever thing to save that pointer,
as we would need to have that pointer once per line, so in large patches
that would save a bit of space, but probably I should not try to be too
smart about it.
So I'd split up the struct line_emission into the two proposed
buffered_patch_line as well as buffered_patch.
However the naming is a bit off than I would expect. Historically you
had one patch per file, so it was natural to name a change of multiple
files a "patchset" (c.f. a commit in Gerrit is called "patchset"/revision)
Today as Git is quite successful, one "patch" is easily understood
as the equivalent of one patch, i.e. what format-patch produced.
So I'd prefer to go with buffer_filepair and buffer_line maybe?
next prev parent reply other threads:[~2016-09-13 23:42 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-13 4:45 [RFC/PATCH 00/17] Stefan Beller
2016-09-13 4:45 ` [RFC/PATCH 01/17] diff: move line ending check into emit_hunk_header Stefan Beller
2016-09-13 14:42 ` René Scharfe
2016-09-13 22:40 ` Stefan Beller
2016-09-13 4:45 ` [RFC/PATCH 02/17] diff: emit_{add, del, context}_line to increase {pre,post}image line count Stefan Beller
2016-09-13 4:45 ` [RFC/PATCH 03/17] diff.c: drop tautologous condition in emit_line_0 Stefan Beller
2016-09-13 4:46 ` [RFC/PATCH 04/17] diff.c: factor out diff_flush_patch_all_file_pairs Stefan Beller
2016-09-13 4:46 ` [RFC/PATCH 05/17] diff.c: emit_line_0 can handle no color setting Stefan Beller
2016-09-13 22:51 ` Junio C Hamano
2016-09-13 4:46 ` [RFC/PATCH 06/17] diff.c: convert fn_out_consume to use emit_line_* Stefan Beller
2016-09-13 22:56 ` Junio C Hamano
2016-09-13 4:46 ` [RFC/PATCH 07/17] diff.c: convert builtin_diff " Stefan Beller
2016-09-13 4:46 ` [RFC/PATCH 08/17] diff.c: convert emit_rewrite_diff " Stefan Beller
2016-09-13 4:46 ` [RFC/PATCH 09/17] diff.c: convert emit_rewrite_lines " Stefan Beller
2016-09-13 4:46 ` [RFC/PATCH 10/17] submodule.c: convert show_submodule_summary to use emit_line_fmt Stefan Beller
2016-09-13 23:02 ` Junio C Hamano
2016-09-13 23:09 ` Stefan Beller
2016-09-13 4:46 ` [RFC/PATCH 11/17] diff.c: convert emit_binary_diff_body to use emit_line_* Stefan Beller
2016-09-13 4:46 ` [RFC/PATCH 12/17] diff.c: convert show_stats " Stefan Beller
2016-09-13 4:46 ` [RFC/PATCH 13/17] diff.c: convert word diffing " Stefan Beller
2016-09-13 4:46 ` [RFC/PATCH 14/17] diff.c: convert diff_flush " Stefan Beller
2016-09-13 4:46 ` [RFC/PATCH 15/17] diff.c: convert diff_summary " Stefan Beller
2016-09-13 4:46 ` [RFC/PATCH 16/17] diff: buffer output in emit_line_0 Stefan Beller
2016-09-13 23:06 ` Junio C Hamano
2016-09-13 23:28 ` Stefan Beller
2016-09-13 23:32 ` Junio C Hamano
2016-09-13 23:42 ` Stefan Beller [this message]
2016-09-13 4:46 ` [RFC/PATCH 17/17] diff.c: color moved lines differently Stefan Beller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGZ79kaFofpU0TMd1ZcJa9UrzdFytg9UjqqtPf8WPXe0zjWihA@mail.gmail.com \
--to=sbeller@google.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).