mikelifeguard@arbour:~/Code/git/stewbot (master)$ git push
gerrit:stewbot HEAD:refs/for/master
Counting objects: 123, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (69/69), done.
Writing objects: 100% (69/69), 32.39 KiB, done.
Total 69 (delta 51), reused 2 (delta 0)
error: unpack failed: error Invalid tree
a39aa6d4a6dcfd6c14d8f818bbdf1dfcb3e11771:mode starts with '0'
To gerrit:stewbot
! [remote rejected] HEAD -> refs/for/master (n/a (unpacker error))
error: failed to push some refs to 'gerrit:stewbot'
(SSH details are in ~/.ssh/config)
Halp!
-Mike
I apologize for the late reply.
There is something wrong with this tree file content. I'm not sure
how that happened. But the error says its got an entry which is not
formatted as expected. What tool(s) have you used recently on this
Git repository that might have been used to create the commit(s)
you are pushing for review here?
Can you send me the binary file that is produced by running
`git cat-file tree a39aa6d4a6d` in your client? Might be best
to wrap it up in a .tar.gz or .zip to prevent a mail client from
doing something smart with half-binary/half-text content.
On 10-03-26 04:24 PM, Shawn Pearce wrote:
> I apologize for the late reply.
I consider this a timely reply - and you're volunteering to help me anyways.
> What tool(s) have you used recently on this
> Git repository that might have been used to create the commit(s)
> you are pushing for review here?
Just git itself. The only commit I've made changed CRLF->LF and removed
trailing whitespace. TBH, this is the first time I've had to deal with
line ending issues, perhaps I made a mistake (but I'd still expect git
to just commit my broken files)
> Can you send me the binary file that is produced by running
> `git cat-file tree a39aa6d4a6d` in your client?
You got it.
Thanks as always,
- -Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkutJV8ACgkQst0AR/DaKHuR5gCglZQkowB12gw5iLx79FfWqzZK
aloAn3mk+d422sX8zYbCX3jpwufi3d2m
=omUE
-----END PGP SIGNATURE-----
What version of git was this? How did you do this CRLF->LF commit?
Because whatever happend, your Git is pretty seriously broken. This
tree shouldn't have a leading 0 in front of its mode.
$ od -c tree
0000000 1 0 0 6 4 4 R E A D M E \0 244 \r
0000020 233 214 350 375 0 263 374 227 264 343 $ 031 027 ` 373 301
0000040 ! h 0 4 0 0 0 0 m o d u l e s
0000060 \0 262 z K 240 4 377 \ 245 C c " 231 377 \n t
0000100 , \n O R E 0 4 0 0 0 0 s t e w
0000120 a r d b o t \0 037 \b 5 262 345 234 034 303 C
0000140 373 335 207 300 u 341 277 \f ] 320 207
0000153
The '0' on the 3rd line after '! h' is wrong. It shouldn't be here.
Likewise the '0' on the 5th line after "O R E" is also wrong. At
least its consistently broken. But its broken:
$ git fsck --full a39aa6d
warning in tree a39aa6d4a6dcfd6c14d8f818bbdf1dfcb3e11771: contains
zero-padded file modes
Gerrit treats this case as a hard failure, because zero-padded file
modes causes the tree SHA-1 to be different, even though its meaning
is the same.
On 10-03-26 06:32 PM, Shawn Pearce wrote:
> What version of git was this?
1.7.0.3
> How did you do this CRLF->LF commit?
When I cloned the repository, git status immediately reported that all
files had been modified - every line had changed, and git reported that
CRLF would be converted to LF. I simply ran sed -i to remove trailing
whitespace, and then committed it. How /should/ I have done it?
The project only just started using git - if need be, I can have the
project lead delete the repo on github, rebase to remove that commit,
and re-push. Only he and I would be affected, and we'd just re-clone. Or
is there a less disastrous way?
- -Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkutKbEACgkQst0AR/DaKHt/ZgCgzQptsMN/mVxSE7NS8Ev2jtZV
3LMAoJJhvW4+aP8coeGUyKLnYDM4PwF7
=Cv5l
-----END PGP SIGNATURE-----
How was this project converted to Git?
I can't find a way for this tree mode to have picked up a leading '0'
like that. The code that writes these out is using vsnprintf with a
format code of "%o". There is no reason why it would use "040000" and
later also use "100644" without the leading '0'. Unless this was
written by a different Git implementation, like say Dulwich or JGit.
Or somebody else's home brew stuff.
I moved this thread over the Git mailing list for a while [1]. It
turns out this is caused by the web based editor on GitHub [2].
[1] http://thread.gmane.org/gmane.comp.version-control.git/143288
[2] http://support.github.com/discussions/repos/2566-strange-warning-from-fsck-and-github-repo-using-too-much-diskspace