Re: [PATCH 3/3] Teach git-index-pack how to keep a pack file.

From: Junio C Hamano <junkio@cox.net>
Date: Oct 29, 2006, 19:14 UTC
Message-ID: <7vr6wr0wa7.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <ei210e$dfs$1@sea.gmane.org>

Jakub Narebski <jnareb@gmail.com> writes:

> Wouldn't it be better to use 'git-index-pack', perhaps with source URL if
> possible, as the default 'why'?

I think it is sensible that Shawn did keep="reason" because git-index-pack usually cannot decide. .keep would be around for at least three reasons:

 - you as the repository owner want to keep the pack from
   repacked because that is the big "initial clone" pack;

 - somebody fetched with --keep and index-pack created .keep
   flag, but somehow the fetch-pack after updating the refs
   failed to remove the flag (or has not finished);

 - somebody pushed into the repository with --keep but somehow
   the receive-pack after updating the refs failed to remove the
   flag (or has not finished);

For a shared repository settings, the person who cares about .keep is the person who logged onto the machine with the repository and ran "clone" (or "init-db && fetch-pack") to prepare the initial state, and fetching would be done by smaller group of people than pushing into it. So these three kinds need to be easily distinguishable by the repository owner. The first kind would not be usually removed; the second one the owner is likely to know if that fetch is still running, and if it is known that fetch is not running then .keep should probably be removed. The third kind is harder to tell if it is safe to remove .keep because usually more people can push into it than fetch into it.

It might be a good idea to leave process ID of the caller of the index-pack as part of --keep="reason" string, along with the timestamp to help the user decide if the .keep is leftover or still in progress (the timestamp can be seen from ls -l *.keep so it is not strictly needed).