Eugene V. Lyubimkin wrote:
> I am not familiar with git's code, so can't analyze much.
>
> Instead, as the real cause was the fact that I set remote to read-only
> address, can this be checked by client side by checking the scheme of remote
> URI? E.g. at least warning ("you are trying to push to read-only repository").
The thing is, push over git:// is a perfectly valid thing to do, even
if it is rare because unauthenticated. It might make sense to give
advice based on the _hunch_ that the other side must be read-only, but
that would be annoying in cases where the heuristic proves wrong.
It would be much better IMHO for git to _know_ that the other end is a
read-only repository, or could not fork for lack of address space, or
is failing for whatever reason. For this, the git protocol needs a
slight change to make the error information available.
Or maybe the git protocol would already allow it. I am not very
familiar with the git protocol. It’s a matter of whether there is a
chance to for the server to negotiate a side channel (the
side-band-64k capability) before it is time to hang up.
For reference, some _similar_ (but not identical) work is in progress
to support transfering output from hooks over HTTP [1].
Anyway, thanks for the report. I will be thinking more about this.
Hoping that is clearer,
Jonathan
[1] See commit 6d525d (receive-pack: Send hook output over side band
#2, 2010-02-05).
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
