Steven Grimm <koreth@midwinter.com> writes:

quoted text
> Shouldn't the repository be locked against operations like prune while
> a commit is in progress anyway? That seems like it's pretty prudent
> and reasonable to me -- doing otherwise is just asking for a zillion
> little race conditions.

The primary problem is not "while a commit is in progress"
anyway.  I do not think of a single sane reason to run git-prune
from a cron job in a repository that is used for an active
development.  It would make sense for management types to run
count-objects from a cron job and yell at offenders to repack,
but even then the primary disk saving and performance
enhancement would come from repacking and not from pruning.
Especially, 1.5.0 and onwards the objects reachable from reflog
are protected from pruning and reflogs are enabled by default
for developer repositories with working trees, even rewind and
rebae would not create crufts (the only two exceptions that
create cruft are running "git add" more than once on the same
file between commits to leak blobs and intermediate tree objects
recursive merge needs to make when there are more than one
common ancestors).

It is a possibility to have a single timestamp file that any
command that intends to eventually update refs should touch
before it starts creating any object.  Then prune can stat the
file and remember its timestamp before it starts reading the
refs, and then before starting to actually prune the objects it
can stat the file again and if the timestamp is different it can
abort.  Commit, receive-pack (invoked by git-push from the
remote side), fetch-pack (invoked by clone, fetch and pull), etc.
all needs to touch the file upfront before they create even a
single object.  But that would create a very hot spot on the
filesystem, and I am not sure what its ramifications are.

My take on this issue is rather different.  I do agree with you
that prune is a rare enough operation, and I think it should not
penalize the primary thing developers would want to do many
times an hour.  I think its much simpler and saner to teach
people not to run prune in an uncontrolled way.

We may want to remove the call to git-prune from git-gc, and
tell people that if they want to run something from a cron job,
run git-gc and not git-prune.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html