Jeff King writes:
> I dunno. This seems like a lot of manual scrambling to try to overcome
> unlikely errors just to make our stderr heard (and we'd still fail in
> some cases). It seems like:
>
> if (fstat(...)) {
> /* weird, fstat failed; try our best to mention it */
> error_errn
> -Original Message-
> From: Jeff King [mailto:p...@peff.net]
> Sent: Friday, February 10, 2017 3:09 PM
> To: David Turner
> Cc: git@vger.kernel.org; pclo...@gmail.com
> Subject: Re: [PATCH v3] gc: ignore old gc.log files
>
> On Fri, Feb 10, 2017 at 02:20:19PM -
On Fri, Feb 10, 2017 at 08:44:27PM +, David Turner wrote:
> > But maybe there are other systems emulating fstat() would trigger here.
> > I dunno.
>
> Yeah, I'm also not sure. On the other hand, if we're going to catch fstat
> errors anyway, we might as well do something sensible with this
On Fri, Feb 10, 2017 at 02:20:19PM -0500, David Turner wrote:
> @@ -76,10 +77,47 @@ static void git_config_date_string(const char *key, const
> char **output)
> static void process_log_file(void)
> {
> struct stat st;
> - if (!fstat(get_lock_file_fd(&log_lock), &st) && st.st_size)
> +
Junio C Hamano writes:
> David Turner writes:
> ...
>> It might still happen that manual intervention is required
>> (e.g. because the repo is corrupt), but at the very least it won't be
>> because Git is too dumb to try again.
>
> Thanks, nicely explained.
Sorry but I spotted a typo "whre" and
David Turner writes:
> It would be good if automatic gc were useful to server operators.
> A server can end up in a state whre there are
> lots of unreferenced loose objects (say, because many users are doing
> a bunch of rebasing and pushing their rebased branches). Before this
> patch, this sta
Git should never get itself into a state where it refuses to do any
maintenance, just because at some point some piece of the maintenance
didn't make progress.
In this commit, git learns to ignore gc.log files which are older than
(by default) one day old. It also learns about a config, gc.logExp
7 matches
Mail list logo