Re: [PATCH v4] gc: call "prune --expire 2.weeks.ago" by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

> ---prune::

I am fairly paranoid about end users wondering about what is described in
ancient documentation and complaining that we do not talk about it
anymore.  I am tempted to suggest:

	This is a no-op but you may see it mentioned in older docs and
	scripts.  Older git-gc never ran 'prune' without being told, and
	this option was a way to tell it to.

but this would lead to littering the documentation with too much
historical information in the long run.  I dunno.  I am inclined to favor
the removal as your patch did, but somebody else may have clever ideas.

> +	if (!strcmp(var, "gc.pruneexpire")) {
> +		if (!value)
> +			return config_error_nonbool(var);
> +		if (strcmp(value, "now") &&
> +				approxidate(value) - approxidate("now") >= 0)
> +			return error("Invalid gc.pruneExpire: '%s'", value);

Yuck; approxidate() returns ulong.  Can subtracting a ulong from another
ever go negative?

Besides, because there is no guarantee of the order of evaluation between
these two approxidate() calls, you may get +1 or -1 on the second boundary.

I think the reason why you did not catch it in your test is because your
tests are half complete; they test only what you wanted to catch
(misconfigured case) and do not test the other half (properly working
case).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux