git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: David Aguilar <davvid@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Git Mailing List" <git@vger.kernel.org>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH v6 4/5] difftool: refactor dir-diff to write files using a helper function
Date: Thu, 30 Sep 2021 16:34:50 -0700	[thread overview]
Message-ID: <CAJDDKr78WcoWjeZqz3c_bdt3s0RRg8Hx9-wC1VFmpy2yPbpbqA@mail.gmail.com> (raw)
In-Reply-To: <xmqq35plaetp.fsf@gitster.g>

On Thu, Sep 30, 2021 at 3:17 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> David Aguilar <davvid@gmail.com> writes:
>
> > This is cleanup refactoring that Junio suggested when
> > 5bafb3576a (difftool: fix symlink-file writing in dir-diff mode, 2021-09-22)
> > touched this area of the code.
>
> Not really what I would want to take credit for  ;-)

Likewise, even I don't like to take credit for my scrappy patches sometimes ;-)

I'll reword this to avoid mentioning the review context.


> > +static void write_entry(const char *path, const char *content,
> > +                     struct strbuf *buf, size_t len)
> > +{
> > +     if (!*content)
> > +             return;
>
> I am not sure "this function is unable to write an empty file" is a
> limitation we want to give to an otherwise more or less generic
> helper function that may be useful in this file (it probably is not
> very useful outside difftool, as what add_path() does seems quite
> specific to it).


Good point, I'll move the conditional checks into the call sites
rather than having it in the helper. It'll read a little more clearly that
way as well.


> Also, is "write entry" a good name for this helper?  The fact that
> the contents came from entry->$side is lost inside this callee.  It
> looks more like "create a file for <path> and write <content> to it",
> i.e. a variant of write_file() but inside the tree specified by the
> extra <buf, len> pair.  So perhaps
>
>         write_file_in_directory(buf, len, path, content);
>
> to match how the write_file() takes its parameters?  While
> write_file() takes a single pathname with the payload, this thing
> takes three parameters <buf, len, path> to specify to which
> "file-in-directory" the payload is written.
>
> > +     add_path(buf, len, path);
> > +     ensure_leading_directories(buf->buf);
> > +     unlink(buf->buf);
> > +     write_file(buf->buf, "%s", content);
> > +}
>
> Other than these two minor points, this looks good to me.

write_file_in_directory() is much clearer. I'll adjust the signature
in the next version.

Thanks for the review. I'll wait to hear back about 3/5 before sending v7.
-- 
David

  reply	other threads:[~2021-09-30 23:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30 17:01 [PATCH v6 1/5] difftool: create a tmpdir path without repeated slashes David Aguilar
2021-09-30 17:01 ` [PATCH v6 2/5] difftool: add a missing space to the run_dir_diff() comments David Aguilar
2021-09-30 17:01 ` [PATCH v6 3/5] difftool: avoid returning -1 to cmd_main() from run_dir_diff() David Aguilar
2021-09-30 22:06   ` Junio C Hamano
2021-09-30 23:25     ` David Aguilar
2021-10-01  0:12       ` Junio C Hamano
2021-09-30 17:01 ` [PATCH v6 4/5] difftool: refactor dir-diff to write files using a helper function David Aguilar
2021-09-30 22:17   ` Junio C Hamano
2021-09-30 23:34     ` David Aguilar [this message]
2021-09-30 17:01 ` [PATCH v6 5/5] difftool: remove an unnecessary call to strbuf_release() David Aguilar
2021-09-30 21:45 ` [PATCH v6 1/5] difftool: create a tmpdir path without repeated slashes Junio C Hamano

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=CAJDDKr78WcoWjeZqz3c_bdt3s0RRg8Hx9-wC1VFmpy2yPbpbqA@mail.gmail.com \
    --to=davvid@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.
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).