David Kastrup <dak <at> gnu.org> writes: > chris <jugg <at> hotmail.com> writes: > > That said I would naively assume that a server side house keeping > > operation that does not get invoked with every client request be a > > nice candidate for asynchronous handling without any need to tell the > > client about it. > > Except that there are _no_ asynchronously handled repository actions > executed on behalf of a client action. If the repository owner decided > to disable demand-based garbage collection in favor of a cron job, > that's his call to make. It makes some sense when there are frequent > and multiple accesses to the repository since it avoids getting denied > access because of somebody _else_ triggering garbage collection > predominantly when times are busiest. > > Usually you are not denied access by your _own_ garbage collection since > the client waits until completion. > > It would be quite bad for scripting git if you constantly had to check > after every action whether any associated garbage collection might or > might not have completed.
I can't comment for every use case, but I find it strange that a client script should need to care whether the server is currently garbage collecting or not. If such a detail must be exposed to a client, then I'd put forth that there is a deeper issue here. But any details there are moving well beyond the scope I'm able to comment on. That said, I think I understand you that it currently does matter in the sense that a client can't perform other actions while garbage collection is running. > Note also that when pushing without a separate server process (like when > pushing into a local repository), there is no other job which could be > responsible for packing the repository rather than the one doing the > push. 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. Regards, Chris -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
