Re: [PATCH] Make git-send-pack exit with error when some refs couldn't be pushed out

From: Junio C Hamano <junkio@cox.net>
Date: Dec 14, 2005, 01:50 UTC
Message-ID: <7vbqzk5tx1.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20051214004540.15040.93518.stgit@machine.or.cz>

Petr Baudis <pasky@suse.cz> writes:

> In case some refs couldn't be pushed out due to an error (mostly the
> not-a-proper-subset error), make git-send-pack exit with non-zero status
> after the push is over (that is, it still tries to push out the rest
> of the refs).

I agree this change to send-pack is a good fix (I haven't looked at the code, but the above description describes a good fix).

However, I am not quite sure if the recent change to Cogito to update the mirror of remote branch is a good one. Since I am not a Cogito user, I did not question it when I saw the change, but I wondered what you are using the cached "remote ref is supposed to be pointing at this commit" knowledge for. If it is only "pretending to have fetched the remote branch immediately after we pushed into it before anybody else touched the same remote branch", then it probably is benign. But this bit puzzles and worries me:

> ... otherwise
> it gets out of sync, which can lead even to loss of commits on the local
> side (this happenned to Jonas Fonseca - thanks for the report, BTW).

I do not remember seeing that report so I do not know how that lossage happens with unreleased Cogito, but I suspect there is something very fishy going on here. I presume it happens when the next fetch/pull from the remote is run, but if the locally cached information can affect the next fetch/pull in such a way, wouldn't updates by other people to the shared remote repository branch also cause things to go out-of-sync and cause the same breakage?