On Thu, Dec 04, 2014 at 10:04:29AM -0800, Junio C Hamano wrote:
> > If it is a problem (and again, I am just guessing), I'd imagine you
> > would need a similar setup to what you proposed for unlink(): before
> > renaming "packed-refs.lock" into "packed-refs", hard-link it into your
> > "trash" ar
Jeff King writes:
> On Wed, Dec 03, 2014 at 01:21:03PM -0800, Brodie Rao wrote:
>
>> > I think it is also not sufficient. This patch seems to cover only
>> > objects. But we assume that we can atomically rename() new versions of
>> > files into place whenever we like without disrupting existing r
On Wed, Dec 03, 2014 at 01:21:03PM -0800, Brodie Rao wrote:
> > I think it is also not sufficient. This patch seems to cover only
> > objects. But we assume that we can atomically rename() new versions of
> > files into place whenever we like without disrupting existing readers.
> > This is the ca
On Mon, Nov 17, 2014 at 1:34 PM, Jeff King wrote:
> On Fri, Nov 14, 2014 at 03:01:05PM -0800, Junio C Hamano wrote:
>
>> > 23 files changed, 375 insertions(+), 7 deletions(-)
>> [...]
>>
>> I am not sure if this much of code churn is warranted to work around
>> issues that only happen on reposito
On Tue, Nov 18, 2014 at 10:59:14AM +1100, Stefan Saasen wrote:
> >> I am not sure if this much of code churn is warranted to work around
> >> issues that only happen on repositories on NFS servers that do not
> >> keep open-but-deleted files available. Is it an option to instead
> >> have a copy
On 18 November 2014 08:34, Jeff King wrote:
>>
>> I am not sure if this much of code churn is warranted to work around
>> issues that only happen on repositories on NFS servers that do not
>> keep open-but-deleted files available. Is it an option to instead
>> have a copy of repository locally o
On Fri, Nov 14, 2014 at 03:01:05PM -0800, Junio C Hamano wrote:
> > 23 files changed, 375 insertions(+), 7 deletions(-)
> [...]
>
> I am not sure if this much of code churn is warranted to work around
> issues that only happen on repositories on NFS servers that do not
> keep open-but-deleted fi
On 15 November 2014 10:01, Junio C Hamano wrote:
>> 23 files changed, 375 insertions(+), 7 deletions(-)
>
> I am not sure if this much of code churn is warranted to work around
> issues that only happen on repositories on NFS servers that do not
> keep open-but-deleted files available. Is it an
Brodie Rao writes:
> This patch adds a gc.garbageexpire setting that, when not set to "now",
> makes gc (and prune, prune-packed, and repack) move garbage into a
> temporary garbage directory instead of deleting it immediately. The
> garbage directory is then cleared out based on gc.garbageexpire
9 matches
Mail list logo
