mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Eric Wong <>
Subject: Re: [PATCH] prune: quiet ENOENT on missing directories
Date: Mon, 21 Nov 2022 15:02:31 +0900	[thread overview]
Message-ID: <xmqq5yf8yhe0.fsf@gitster.g> (raw)
In-Reply-To: <> (Eric Wong's message of "Sat, 19 Nov 2022 20:12:13 +0000")

Eric Wong <> writes:

> $GIT_DIR/objects/pack may be removed to save inodes in shared
> repositories.  Quiet down prune in cases where either
> $GIT_DIR/objects or $GIT_DIR/objects/pack is non-existent,

Wouldn't setup.c::is_git_directory() say "nope, you do not have a
repository there" if you are missing $GIT_DIR/objects?  So I suspect
that the only case this matters in practice is a missing pack/

I agree that silently ignoring missing objects/pack/ is perfectly
fine, whether we auto-vivify it when we actually create a pack.

> but emit the system error in other cases to help users diagnose
> permissions problems or resource constraints.


> @@ -127,7 +127,9 @@ static void remove_temporary_files(const char *path)
>  	dir = opendir(path);
>  	if (!dir) {
> -		fprintf(stderr, "Unable to open directory %s\n", path);
> +		if (errno != ENOENT)
> +			fprintf(stderr, "Unable to open directory %s: %s\n",
> +				path, strerror(errno));
>  		return;
>  	}

This is called twice, with $GIT_OBJECT_DIRECTORY and its pack
subdirectory, as it does not recurse.  

This is a tangent, I have to wonder how effective the first call
would be, though.  When writing a loose object file, we compute its
object name first in-core and determine the final filename, create a
temporary file in the same directory as the final file, write into
it and then finally rename the temporary to the final name.  The
fan-out $GIT_OBJECT_DIRECTORY/??/ directories may have temporary
files left when such a process crashed, but do we create cruft "git
prune" should remove in $GIT_OBJECT_DIRECTORY/ itself?

> diff --git a/t/ b/t/
> index 8ae314af58..d65a5f94b4 100755
> --- a/t/
> +++ b/t/
> @@ -29,6 +29,14 @@ test_expect_success setup '
>  	git gc
>  '
> +test_expect_success 'bare repo prune is quiet without $GIT_DIR/objects/pack' '
> +	git clone -q --shared --template= --bare . bare.git &&
> +	rmdir bare.git/objects/pack &&
> +	git --git-dir=bare.git prune --no-progress 2>prune.err &&
> +	test_must_be_empty prune.err &&
> +	rm -r bare.git prune.err
> +'
> +
>  test_expect_success 'prune stale packs' '
>  	orig_pack=$(echo .git/objects/pack/*.pack) &&
>  	>.git/objects/tmp_1.pack &&

  reply	other threads:[~2022-11-21  6:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-19 20:12 [PATCH] prune: quiet ENOENT on missing directories Eric Wong
2022-11-21  6:02 ` Junio C Hamano [this message]
2022-11-21 10:44   ` Eric Wong
2022-11-21 13:08     ` Junio C Hamano
2022-11-21 23:09       ` Junio C Hamano
2022-11-22  0:09         ` [PATCH] prune: recursively prune objects directory Eric Wong
2022-11-22  1:28           ` Junio C Hamano
2022-11-22  9:59             ` Eric Wong
2022-11-22 23:16               ` Junio C Hamano
2022-11-21 11:16 ` [PATCH] prune: quiet ENOENT on missing directories Ævar Arnfjörð Bjarmason

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq5yf8yhe0.fsf@gitster.g \ \ \ \

* 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

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).