chris <> writes:

> Ok, given your full response, I understand how this is being
> conceptualized now, thanks.  However, if you look at it purely from a
> user's perspective who is manually invoking these commands for the
> command's primary purpose, the current behavior is annoying.
> If we assume Git is right in implementing that no server async actions
> are executed on behalf of a client action, then this falls under the
> category of an ill-behaved server in my opinion.  Anything a server
> does that is not directly related to fulfilling the requested client
> action is now considered bad behavior as it blocks the client from
> continuing whatever it needs to get on with.  I see such
> implementation in Git as favoring server's needs over clients.

There are no "server's needs" at all.  Git only reacts to client
requests.  It is in the clients' own interest when garbage collection is
periodically done since it improves response time.

It's arguable that it would be nicer to use an incremental compaction
process that hides the periodic costs by distributing them over the
request totality.  That replaces the periodic "why does it have to
garbage collect when _I_ am using it" annoyance with "why is this
generally slow".  There is no net benefit to that approach safe for

a) avoiding complaints of "smart" people who have discovered that they
can speed up git by disabling garbage collection, but eventually find
that git is becoming slow for them but not for others.
b) avoiding these mailing list discussions.

The second benefit could likely be achieved by displaying "Server
unreachable... retrying..." instead of reporting about git gc.

David Kastrup

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to