Re: [PATCH v3 0/2] Correctly handle transient files in shared repositories

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

 



On Mon, Jan 11, 2016 at 01:54:05PM -0800, Junio C Hamano wrote:

> Jeff King <peff@xxxxxxxx> writes:
> 
> > I'm not sure I buy this argument. Yes, you should not be writing
> > anything else, but that does not change the fact that "fsck" will
> > unceremoniously abort:
> > ...
> > So I think this would be a reasonable candidate (or alternatively, to
> > treat EPERM on an existing file as a soft error). I am totally fine not
> > to address it as part of this series, though.
> 
> Yeah, that crossed my mind (and I agree with the conclusion).
> 
> Listing what is left deliberately and why is still a good idea, as
> that would force people to think twice before wasting effort to
> convert blindly without thinking.  Listing what is left behind like
> "git fsck" that we know we shouldn't leave behind is even better to
> mark low-hanging fruits.  How do you like this one instead?
> 
>      - git fsck, when writing lost&found blobs (this probably should
>        be changed, but left as a low-hanging fruit for future
>        contributors).

I think that's more accurate. :)

-Peff
--
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]