该树包含一个具有无效路径'.git'的条目 [英] The tree contains an entry with an invalid path of '.git'

查看:226
本文介绍了该树包含一个具有无效路径'.git'的条目的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前正在将项目从Team Foundation版本控制转移到 Git 。我已经使用 git-tf 成功完成了两次,将代码下载到本地git存储库中,然后将该存储库推送到新的远程存储库。



在我的第三个项目中,当我尝试推送时,出现以下错误


error:unpack failed:error树对象
e934502276892b903347a524cb066a14a19d8ac0被拒绝:树
包含一个具有无效相对路径'.git'的条目。


我不知道这可能是什么,因为当我推送到 TFS GitHub的。我会很感激,如果有人有一个想法如何补救。



谢谢!

解决方案由于一些安全方面的原因,Git拒绝在任何名为 .git 的目录中存储任何文件。 (如果Git 允许 .git 文件,一个名为 .git / hooks / commit 的文件>在Git仓库中将成为您的提交钩子,并且您运行的下一个提交将会运行攻击者放入该文件的任何任意命令。有一个检查可以避免这种情况,但事实证明它略有损坏。)对于特定于实现原因是这个特定的安全问题显示为包含'.git'的错误树对象,它通过 hasDotGit 1 配置。

然而,并非每一个版本的Git都有各种测试,并且随着多年来发现的新问题,新版本的Git获得了针对这些老问题的新保护。如果有一个旧版本的Git,你的Git可能会允许不安全的和/或不正确的项目 - 比如这个坏的对象 - 是存储。升级到更新版本的Git,或者在某个服务器上访问更新版本的Git,有时会诊断甚至开始拒绝使用一个糟糕的存储库。



从Git 2.6版开始,您可以配置Git接受某些不正确的资源库项目,即使您一般打开了检查。 (在2.6之前,您必须完全关闭检查。)您可以选择忽略某些问题,将某些问题降级到警告级别,将警告升级为错误,和/或通过其哈希ID忽略某些特定对象。这个配置必须在服务器上完成 我不知道它是否以及如何在您使用的服务器上完成。另请参阅此GitLab论坛发帖,这表明某人或某人已经随着时间的推移关闭它。

作为参考,Git版本2.2.1,2.1.4,2.0.5,1.9.5和1.8.5是Git开始检查 .git 以NTFS和MacOS(HFS)特定方式拼写并且不区分大小写的点(在此之前, .Git <例如,code>或 .gIt .GIT 都可以接受为OK在Linux / Unix系统上)。这些检查位于 fsck.c 中,并可在所有包上传,下载和索引操作中调用。查看 git config 文档,搜索 fsck 的每个实例,因为有许多配置旋钮可启用或禁用检查完全或改变问题的严重性。

为了将 hasDotGit 的严重性降低到警告,您会这样做:

  $ git config fsck.hasDotGit警告
code>

在特定的存储库中。



除了重新配置服务器之外,您还可以选择重写不良资料库的历史记录(使用 git filter-branch ),使其成为一个良好的资料库。如果你这样做了,你将基本上迫使所有用户重新克隆。






1 文本消息的确切形式经历了国际化,但默认情况下包含'.git',配置字符串为 hasDotGit



配置字符串并不明显,似乎也没有正确记录。它们是通过在fsck.c源文件中使用枚举名称,然后去除所有下划线,并将其转换为小写字母,然后重新设置大写字母,然后重新制作驼峰名称。 ( git config 字符串比较是用大小写不敏感的方式完成的,所以你可以配置 fsck.hasdotgit fsck.HASDOTGIT ,如果你喜欢的话。驼峰只是一个惯例。)


I am currently in the process of transferring projects from Team Foundation Version Control to Git. I have successfully done this twice using git-tf to download the code into a local git repository and then push that repository to a new remote repository.

On my third project, I am getting the following error when I attempt to push:

error: unpack failed: error The tree object e934502276892b903347a524cb066a14a19d8ac0 was rejected: The tree contains an entry with an invalid relative path of '.git'.

I can not figure out what this might be as it fails when I push to TFS or GitHub. I would be so grateful if someone has an idea of how to remedy.

Thanks!

解决方案

For some good security reasons, Git refuses to store any files within any directory named .git. (If Git did allow .git files, a file named .git/hooks/commit in the Git repository would become your commit hook, and the next commit you ran would run whatever arbitrary commands an attacker put into that file. There's a check to avoid this, but it turned out it was slightly broken.) For implementation-specific reasons this particular security issue shows up as a bad "tree object" that "contains '.git'", which is configured through hasDotGit.1

Not every version of Git has every test, though, and as new problems have been discovered over the years, new versions of Git have acquired new protections against these old problems. If you have an older version of Git, your Git may be allowing insecure and/or incorrect items—such as this bad tree object—to be stored. Upgrading to a newer version of Git, or accessing a newer version of Git on some server, will sometimes diagnose, or even start refusing to work with, a bad repository.

As of Git version 2.6, you can configure Git to accept certain bad repository items, even if you have checking turned on in general. (Prior to 2.6 you must simply turn checking off entirely.) You can choose to ignore some problems, downgrade some issues to warning level, upgrade warnings to errors, and/or ignore some particular objects by their hash IDs. This configuration must be done on the server; whether, and how, it can be done on the servers you are using, I do not know. See also this GitLab forum posting, which suggests that something or someone has been turning this off and on over time.

For reference, Git versions 2.2.1, 2.1.4, 2.0.5, 1.9.5, and 1.8.5 were the points at which Git began checking for .git spelled in NTFS and MacOS (HFS) specific ways and with case insensitivity (before that, .Git or .gIt or .GIT, for instance, were all accepted as OK—which they generally are on Linux/Unix systems). These checks are in fsck.c and are optionally invoked on all pack upload, download, and indexing operations. See the git config documentation, searching for every instance of fsck, as there are numerous configuration knobs to enable or disable checking entirely, or change the severity of issues.

To reduce the severity of hasDotGit to warning, you would do:

$ git config fsck.hasDotGit warning

within that specific repository.

Besides reconfiguring servers, you can also choose to rewrite the history of a bad repository (using git filter-branch) to make it into a good repository. If you do so, though, you will essentially force all your users to re-clone.


1The exact form of the text message undergoes internationalization, but the default is contains '.git' and the configuration string is hasDotGit.

The configuration strings are not obvious, and seem not to be properly documented. They are formed by taking the enumerated names in the fsck.c source and stripping out all underscores and translating to lowercase, then re-upper-casing wherever you like to make camelCase names. (The git config string comparisons are done with case insensitivity, so you can actually configure fsck.hasdotgit or fsck.HASDOTGIT if you like. The camelCase is just a convention.)

这篇关于该树包含一个具有无效路径'.git'的条目的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆