Thread (1 message) 1 message, 1 author, 2018-01-05

Re: [PATCH 3/4] clone: factor out dir_exists() helper

From: Junio C Hamano <hidden>
Date: 2018-01-05 19:19:26

Jeff King [off-list ref] writes:
On Thu, Jan 04, 2018 at 06:54:12PM -0500, Jeff King wrote:
quoted
quoted
If we really want to be anal, perhaps a new helper path_exists()
that cares only about existence of paths (i.e. the implementation of
these two helpers they currently have), together with update to
check the st.st_mode for file_exists() and dir_exists(), may help
making the API set more rational, but I do not think it is worth it.
Yep, I also considered that file_exists() probably wants to be
path_exists() with its current implementation. We'd probably want to
review all of the callers.

Anyway, I tried to do the minimal refactoring here, with no change in
behavior. I'm not opposed to calling this dir_exists() as path_exists()
and making it globally available (as you note, I don't think we'd want
to use a true dir_exists() here).
So I actually started down this road just now, but I'm not sure if it's
worth it.
Yeah, although I said it already without starting down this road,
you actually thought about it more and your insight is more valuable
;-)
If we were to transition to an endgame with path_exists(),
dir_exists(), and file_exists(), we'd probably want to do something
like:

  1. introduce path_exists(), but leave existing file_exists() callers
     in place

  2. introduce file_exists_as_file(), which checks S_IFREG

  3. audit each file_exists() call to see if it ought to be
     path_exists() or file_exists_as_file() and convert as needed

  4. When there are no more file_exists() calls left, all
     file_exists_as_file() instances can be renamed to file_exists().

But as with any "audit each..." plan, that leaves topics in flight out
of luck. If we want to be kind to those, we'd have to wait a long while
to shake out any file_exists() callers.

At which point is there much value in having path_exists() as a wrapper?
It's a better name, perhaps, but I think my future-proofing against
"file_exists() may become file-specific" was probably overly paranoid. I
don't think we could sanely do that conversion without risking breakage.
If we want to, the endgame can be to have a single path_exists_as()
helper that could be used like so:

	#define PATH_TYPE_IFREG	(1<<0)
	#define PATH_TYPE_IFLNK (1<<1)
	#define PATH_TYPE_IFDIR (1<<2)
	#define PATY_TYPE_IFANY ((1<<3)-1)

	#define path_exists(path) path_exists_as(path, PATH_TYPE_ANY)
	#define path_exists_as_file(path) path_exists_as(path, PATH_TYPE_IFREG)

	/* backward compatibility */
	#define file_exists(path) path_exists_as(path, PATH_TYPE_ANY)

We can avoid "file-exists used to mean this thing but in a distant
future it means completely different thing" that way.
Maybe we should just document its behavior and use it here, rather than
introducing this new dir_exists().
Sounds good enough to me ;-)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help