git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Miriam Rubio <mirucam@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [Outreachy] [PATCH] dir: add new function `path_exists()`
Date: Mon, 28 Oct 2019 11:22:40 +0900	[thread overview]
Message-ID: <xmqqy2x5a9sf.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20191027163038.47409-1-mirucam@gmail.com> (Miriam Rubio's message of "Sun, 27 Oct 2019 17:30:38 +0100")

Miriam Rubio <mirucam@gmail.com> writes:

> Added a new function path_exists() that works the same as file_exists()
> but with better descriptive name.

"I did this" before justifying why it is a good thing is not a good
description.

	builtin/clone.c has a static funciton dir_exists() that
	checks if a given path exists on the filesystem.  It returns
	true (and it is correct for it to return true) when the
	given path exists as a non-directory (e.g. a regular file).

	This is confusing.  What the caller wants to check, and what
	this function wants to return, is if the path exists, so
	rename it to path_exists().

would make sense (and follows our convention to command the codebase
to "become like so").

> New calls should use path_exists() instead of file_exists().

This is not a good suggestion in general, and I do not want to see
such a statement here or (more importantly) not in the header file.
Calls that want to see if the path exists, regardless of type,
should use path_exists() instead of file_exists().  Other calls that
should be checking if a regular file exists there should continue to
use file_exists().  Once we finished sweeping code, one of two
things could happen:

 (1) there remains no caller to file_exists()---it turns out that
     everybody wanted to check if there is something at the given
     path, no matter what type of filesystem entity it is.  In such
     a case, we can safely remove file_exists().

 (2) there are legitimate callers to file_exists()---these callers
     used "does stat() succeed?" without checking if the filesystem
     entity at the path is indeed a regular file, but that was what
     they wanted to do.  In such a case, we can tighten the check in
     file_exists() to also make sure that we saw a regular file.

If you audited all existing callers of file_exists() as a part of
preparing this topic, and if the result is (1) above, then I think
this single patch as the whole of this topic is OK.  But if so, the
proposed log message should state that fact to justify the above
statement.  Also we may want to remove the implementation of
file_exists() and replace it with

	#define file_exists(path) path_exists(path)

in dir.h if we were to go that route.

I actually suspect that you would rather one to go in the other
direction, i.e. to narrow the scope of this topic and change the
dir_exists() to path_exists() inside builtin/clone.c, leaving the
function file-scope static, and stop there.  Unless/until all the
existing callers of file_exists() have been audited and we know all
of (or at least "most of") them want to ask "does anything exist at
this path?", that would be the more sensible thing to do.

Thanks.

  reply	other threads:[~2019-10-28  2:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-27 16:30 [Outreachy] [PATCH] dir: add new function `path_exists()` Miriam Rubio
2019-10-28  2:22 ` Junio C Hamano [this message]
2019-10-28  9:45 ` Carlo Arenas

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=xmqqy2x5a9sf.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=mirucam@gmail.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).