From: Tobias Klauser <tklauser@distanz.ch>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: Tobias Klauser <tobias.klauser@zhinst.com>,
Junio C Hamano <gitster@pobox.com>,
Christian Couder <chriscool@tuxfamily.org>,
git@vger.kernel.org
Subject: Re: [PATCH] interpret-trailers: add option for in-place editing
Date: Wed, 6 Jan 2016 15:36:36 +0100 [thread overview]
Message-ID: <20160106143635.GI29125@distanz.ch> (raw)
In-Reply-To: <vpqoacylri6.fsf@anie.imag.fr>
Thanks for your feedback Matthieu!
On 2016-01-06 at 15:19:45 +0100, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> Tobias Klauser <tobias.klauser@zhinst.com> writes:
>
> > From: Tobias Klauser <tklauser@distanz.ch>
> >
> > Add a command line option --in-place to support in-place editing akin to
> > sed -i. This allows to write commands like the following:
>
> Since -i is a common shortcut for --in-place (perl -i, sed -i), it
> probably makes sense to have it here too. OTOH, this is meant for
> scripting and perhaps it's best to force script writters to be verbose.
Yes, I thought this would mainly be used in scripts and thus omitted the
short option.
> > Also add the corresponding documentation and tests.
>
> This sentence does not harm, but I personnally don't think it's really
> helpfull, as it's already clear by the diffstat right below, and the
> patch itself.
Ok, I can omit it for v2.
> > -static void print_tok_val(const char *tok, const char *val)
> > +static void print_tok_val(FILE *fp, const char *tok, const char *val)
> > {
> > char c = last_non_space_char(tok);
> > if (!c)
> > return;
> > if (strchr(separators, c))
> > - printf("%s%s\n", tok, val);
> > + fprintf(fp, "%s%s\n", tok, val);
> > else
> > - printf("%s%c %s\n", tok, separators[0], val);
> > + fprintf(fp, "%s%c %s\n", tok, separators[0], val);
> > }
>
> The patch would be even easier to read if split into a preparatory
> refactoring patch "turn printf into fprintf" and then the actual one.
> But it's already rather clear, so you can probably leave it as-is.
Ok. I have also no problem with splitting it. I'll wait for a feedback
from Junio on what he prefers.
> > -static void print_lines(struct strbuf **lines, int start, int end)
> > +static void print_lines(FILE *fp, struct strbuf **lines, int start, int end)
>
> Here and below: it would probably be more readable with a more explicit
> name for fp, like "outfile". Especially here:
>
> > -static int process_input_file(struct strbuf **lines,
> > +static int process_input_file(FILE *fp,
> > + struct strbuf **lines,
>
> Where it's tempting to think that a parameter given to
> process_input_file is ... the input file!
Yes, makes sense. I'll change it to a more concise and readable name
I'd also take "outfile" as you suggest, unless anyone objects.
Thanks
Tobias
next prev parent reply other threads:[~2016-01-06 14:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-06 13:34 [PATCH] interpret-trailers: add option for in-place editing Tobias Klauser
2016-01-06 14:19 ` Matthieu Moy
2016-01-06 14:36 ` Tobias Klauser [this message]
2016-01-06 19:02 ` Eric Sunshine
2016-01-07 12:42 ` Tobias Klauser
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160106143635.GI29125@distanz.ch \
--to=tklauser@distanz.ch \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=tobias.klauser@zhinst.com \
/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.
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 NNTP newsgroup(s).