Jeff King <peff@xxxxxxxx> writes: > I was a bit loose with my phrase 'commit operation'. What I really mean > is: > > $ git add file ;# (1) > $ hack hack hack ;# (2) > $ git commit ;# (3) > > After step (1), you have a blob in your db. If you already had that > blob, then you have the old blob. You don't get the updated tree and > commit until step (3). Step (2) can be hours or days. Do you really want > to lock the repository that long? This case does not need any locking, as blobs reachable from index are considered as "reachable" for the purpose of pruning. - 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