On Fri, Jan 20, 2017 at 2:00 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Duy Nguyen <pclouds@xxxxxxxxx> writes: > >> On Mon, Jan 9, 2017 at 9:34 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Duy Nguyen <pclouds@xxxxxxxxx> writes: >>> >>>> On Sun, Jan 8, 2017 at 4:46 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>>>> Christian Couder <christian.couder@xxxxxxxxx> writes: >>>>> >>>>>> So what should we do if freshen_file() returns 0 which means that the >>>>>> freshening failed? >>>>> >>>>> You tell me ;-) as you are the one who is proposing this feature. >>>> >>>> My answer is, we are not worse than freshening loose objects case >>>> (especially since I took the idea from there). >>> >>> I do not think so, unfortunately. Loose object files with stale >>> timestamps are not removed as long as objects are still reachable. >> >> But there are plenty of unreachable loose objects, added in index, >> then got replaced with new versions. cache-tree can create loose trees >> too and it's been run more often, behind user's back, to take >> advantage of the shortcut in unpack-trees. > > I am not sure if I follow. Aren't objects reachable from the > cache-tree in the index protected from gc? I think the problem is loose objects created then gc run just before they are referenced (e.g. index written down). But I think I may be following a wrong road. If mtime is in fact to deal with race conditions, applying the same idea here is wrong because we have a different problem here. > Not that I think freshening would actually fail in a repository > where you can actually write into to update the index or its refs to > make a difference (iow, even if we make it die() loudly when shared > index cannot be "touched" because we are paranoid, no real life > usage will trigger that die(), and if a repository does trigger the > die(), I think you would really want to know about it). -- Duy