chris <jugg@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html