On Oct 7, 10:43 am, Simon Lipp <slo...@gmail.com> wrote:
> > Very interesting.
> > What happens if you clone on the same host?
> > $ cd /tmp/foo
> > $ git clone /path/to/test
> > or
> > $ git clone file:///path/to/test
> > ?
> > If it fails, try looking at `git fsck`.
> On the local side, git clone works and git fsck only indicate some
> dandling blob and commits (that's my bad habit of doing git reset
> --hard HEAD^ ;)). On the remote machine :
> broken link from    tree 869a1d54960d405d661e747c1c056a59cc8d2e9b
>               to    blob 719d3089ebb11eba608b13070c4e35be5e3969d6
> missing blob 719d3089ebb11eba608b13070c4e35be5e3969d6
> But it’s an old version of git on the remote machine ( — I’m not
> the admininstrator and he’s not willing to upgrade.
> I said that there’s no problem with the local machine, but it’s only
> for cloning. The problematic directory also has problems here :
> $ git ls-tree master
> 160000 commit 719d3089ebb11eba608b13070c4e35be5e3969d6  DesktopChaos
> The interesting part is :
>  - 160000 for a directory. It’s the only directory with this mode. I
>    don’t know what it means though.
>  - the directory is a blob for git
>  - the directory is a commit for git 1.7.3
> The commit that introduced the problematic directory is
> f3ef8b57e8e71b44c9c669d32b16faf82c643fce. git log on the remote side
> gives up with:
> fatal: corrupt tree sha 719d3089ebb11eba608b13070c4e35be5e3969d6
> On the local side, better luck:
> diff --git a/htdocs/themes/DesktopChaos b/htdocs/themes/DesktopChaos
> new file mode 160000
> index 0000000..719d308
> --- /dev/null
> +++ b/htdocs/themes/DesktopChaos
> @@ -0,0 +1 @@
> +Subproject commit 719d3089ebb11eba608b13070c4e35be5e3969d6
> But I don’t remember creating a subproject. In fact, I don’t even know
> what is a subproject under git :)

Heh, this makes (some) sense in fact: googling for "git file mode
160000" yields, among others, a reference to [1] which contains an
example with that same file mode, and that section is about Git
submodules. Submodules are, well, a way to maintain several
independent repositories tied together.
Now, according to [2] the support for submodules was added in 1.5.3
and your remote git is unaware about this functionality.
Hence, I think there's a good chance that all this happens just
because remote Git chokes on that file mode it simply does not know
and treats as invalid.

The solutions seems to be is to rebase a necessary branch and delete
that f3ef8b57e8e71b44c9c669d32b16faf82c643fce commit. Note that I'm
not completely sure; I'm thinking this way: if you don't know what
submodules are you're most probably not using them and that reference
to a submodule is just some artifact of a earlier development, and
*possibly* it can be removed as it seemingly just records the commit
which Git should consider as "current" with regard to that submodule.
Check the docs on submodules to be sure.

1. http://progit.org/book/ch6-6.html
2. https://git.wiki.kernel.org/index.php/SubprojectSupport

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to