Linus Torvalds [off-list ref] writes:
On Mon, 16 Apr 2007, Christian wrote:
quoted
We have moved from CVS to git in the beginning of last week, all went well
until this weekend. This weekend one developer wanted to push some of his
local modifications, unfortunately during the push his http connection seemed
to have broken or so. Unfortunately git does not prove if the push went well.
Therefore our repository was broken this morning.
I have to agree: pushing over http really is dangerous.
...
Just for the record, I do not think anybody during that #git
discussion actually proved that http-push was the culprit. It
is a very plausible working conjecture, though.
I do not know if Nick is still using his own http-push (or if he
is still using git for that matter), but just in case he may
still be interested, I am cc'ing this message to him.
I'd also love it if somebody were to actually look into making
http-pushing a bit safer. It really needs somebody who cares about it, or
it should likely just be disabled entirely (perhaps with a config option
that you have to enable to get it - so that people *realize* that it's not
maintained and not really supported).
I think the fetch side does the right thing, more or less, by
downloading to a temporary file and using move_temp_to_file()
after validating the SHA-1 matches. I haven't followed the push
side but as we do not have a single line of code on the
receiving end, I would not be surprised if there is no error
checking beyond HTTP response code would give the pushing end.
I would still love to see the corrupt loose object to see how it
is broken.
Christian, can you do this with the first (i.e. older) commit
that is broken, and tar up these 7 files for the initial round
of inspection?
$ git cat-file commit $commit >commit-text 2>commit-error
$ git ls-tree ${commit} >toplevel-tree 2>toplevel-tree-error
$ git ls-tree -r -t ${commit} >whole-tree 2>whole-tree-error
$ cp .git/objects/cd/1aac1a43cfdac07118240f75c0ba7662eb8140 corrupt
On Mon, 16 Apr 2007, Junio C Hamano wrote:
Just for the record, I do not think anybody during that #git
discussion actually proved that http-push was the culprit. It
is a very plausible working conjecture, though.
I looked at http-push.c once more, and there is a very marked lack of any
error testing. It actually tries to be pretty careful, ie it seems that
every PUT request is always to a temp-file, and then it does a MOVE
request after that, and things seem to properly abort on most errors, but
the actual data integrity is obviously impossible to check on the remote,
and a quick grep showed that not all errors even set "aborted", which
would seem to imply that certain error conditions can happen without the
http-push then aborting the ref update.
For example, if "start_active_slot()" fails, aborted isn't generally set.
I don't know if that is ever a problem (it can only trigger with
USE_CURL_MULTI), but it's an example of what looks pretty fragile.
So we can fix up some of these kinds of things, but considering that we
can't really validate the end result on the remote, I'd still personally
be quite leery of pushing by http..
I think the fetch side does the right thing, more or less, by
downloading to a temporary file and using move_temp_to_file()
after validating the SHA-1 matches.
Yeah, on the pulling side we are simply much better off, because we can
validate things after the operation has finished. On the pushing side, we
could obviously try to re-download the objects or something, but basically
validation would literally have to involve doubling the network usage, and
even then we might get screwed by some caching layer!
Linus
hi Junio,
today i got access to the machine with the corrupt git blobs, attached
are the requested files, but there was no error, so i've not attached
the output from stderr.
I hope this helps.
Christian
Junio C Hamano wrote:
Linus Torvalds [off-list ref] writes:
quoted
On Mon, 16 Apr 2007, Christian wrote:
quoted
We have moved from CVS to git in the beginning of last week, all went well
until this weekend. This weekend one developer wanted to push some of his
local modifications, unfortunately during the push his http connection seemed
to have broken or so. Unfortunately git does not prove if the push went well.
Therefore our repository was broken this morning.
I have to agree: pushing over http really is dangerous.
...
Just for the record, I do not think anybody during that #git
discussion actually proved that http-push was the culprit. It
is a very plausible working conjecture, though.
I do not know if Nick is still using his own http-push (or if he
is still using git for that matter), but just in case he may
still be interested, I am cc'ing this message to him.
quoted
I'd also love it if somebody were to actually look into making
http-pushing a bit safer. It really needs somebody who cares about it, or
it should likely just be disabled entirely (perhaps with a config option
that you have to enable to get it - so that people *realize* that it's not
maintained and not really supported).
I think the fetch side does the right thing, more or less, by
downloading to a temporary file and using move_temp_to_file()
after validating the SHA-1 matches. I haven't followed the push
side but as we do not have a single line of code on the
receiving end, I would not be surprised if there is no error
checking beyond HTTP response code would give the pushing end.
I would still love to see the corrupt loose object to see how it
is broken.
Christian, can you do this with the first (i.e. older) commit
that is broken, and tar up these 7 files for the initial round
of inspection?
$ git cat-file commit $commit >commit-text 2>commit-error
$ git ls-tree ${commit} >toplevel-tree 2>toplevel-tree-error
$ git ls-tree -r -t ${commit} >whole-tree 2>whole-tree-error
$ cp .git/objects/cd/1aac1a43cfdac07118240f75c0ba7662eb8140 corrupt
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html