git clone not working. / an admin's rant

[Joachim Steiger]

Cesar Eduardo Barros wrote:

> After it's fixed, do a git fsck --full on _all_ the other repositories
> in that machine. git repositories shouldn't get corrupted that easily,
> and it almost always points to hardware problems.

nope.. it also is rotten enough software to run totally amok when not
getting a socket or some other unix resource due to to hitting a
resource limit (which didn't happen in this case at hand, but i've seen
that before)
no broken hw necessary.

> You could also either
> update git on the server to at least 1.6.0 or set pack.indexVersion to 2
> (the new default on 1.6.0) and do a full repack of everything; the
> resulting packs have extra protection against corruption, but are
> incompatible with git 1.4.4.4[4] or earlier when fetching over http
> (fetching over the native git protocol works, and git 1.4.4.5 also
> works; the error message is a very obscure "non-monotonic index" one).

GAAAH.. sorry, but WTF? do they break compatibility on purpose all the time?
just for the record.. 1.6.0 was released on 17. of august this year. so
its not in _ANY_ stable distro yet. (and 1.6.0.1 on 24th..)

git 1.4.4.5 doesnt exist it seems.
atleast it doesnt show on
http://www.kernel.org/pub/software/scm/git/
at all

i would rule out hw problems, since git runs in a openvz-vm of its own,
and none of the other vms or the host showed recent trouble of that kind.
i rather guess that its (again) git which 'sucks around big time'

sometimes one thinks these guys never had to deal with the real world
outside their heads where people even need to tunnel through https to
get broken proxies not breaking their http and git:// does not work at
all. (and corporate policy hindering em to fix it).

one wouldn't believe how often one hears of such problems once working
as admin ;)

means: currently we run git version 1.4.4.4 on that machine.

if we want to change that, it means somebody again needs to 'bless the
version used' and take care of _maintaining_ that.

currently its us admins maintaining that VM, keeping it up to date with
security patches, while keeping as much as possible on stock versions.
the timestamps on the last few git relases do not make any serious
impression of 'a version we can run some time, without constant taking
care manually'

from time to time i did a local repack like this:
https://admin-trac.openmoko.org/trac/ticket/1492
since there is a warning about some breakage, thats not a cron. (yet)

i would stop doing this, but repo grows substantially and updates as
well as clones are _extremely_ slow when not doing a repack from time to
time.

the even more strange thing is that i didnt run a repack at all in
september yet. afaik.

so: sorry.. aslong as it breaks compatibility with debian stable you
guys need a better idea than 'update to head, we are sure its broken
differently!!11!' *sigh*

too sad.. i started liking git. but when they continue to nag people
with repeated incompatibilities/breakage on the wire or on fs, its are
not worth anything more than mtn, which drove enough people mad beyond
repair with its 'not performance'

> [3] Very recent versions of git should be able to skip the damaged
> objects within the pack and recover the rest while doing a full repack,
> so on them a full repack might be an alternative to removing the damaged
> packs and objects, but if it works it's simpler to remove them.

we need repacks from time to time anyways.

> [4] Only Debian etch (the current stable) still has that old version.
> git 1.4.4.5 was made especially for them; the only change is the ability
> to read (but not write) the version 2 pack index.

my conclusion is that i 'do not change anything', without somebody
having a _very_ convincing explanation why, and what.

upping to 1.6.0 means breaking the wire protocol and their
update-frequency tells me: 'i will not be the idiot running behind these
guys all the time'.

so git-guys, please fix that. find a working version which
 a) doesnt break the repo
 b) can be repacked automated without breaking the repo
 c) does not need manual rebuilding of git packages every half month.
 d) doesnt break compatibility with 1.4 and 1.5 git series. (i guess one
could drop 1.4 compat end of the year or a bit later, but not now. 1.5
probably compat will need to stay another year or 2)


sorry about being a bit harsh, but watching all this madness while 'svn
on fsfs just works' (in most (smaller) usecases ;), makes one quite sad.
(especially because it eats peoples time with stuff which should be
'base technology' and not something changing all the time.

-- 

Joachim Steiger
Openmoko Central Services