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
> 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
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
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