致命:错误的默认修订'HEAD'

Question

我正在使用GIT作为我的源代码控制系统.我们将它安装在我们的一个Linux机器上.Tortoise GIT是我的Windows客户端.

今天早上我检查了一些更改,并标记了代码.然后我将我的本地存储库推送到远程存储库.

当我在unix盒子上找到我的存储库并输入时,git log我得到:

fatal: bad default revision 'HEAD'

但当我show log使用我的Windows tortoiseGit客户端时,历史很好地按照以下方式出现......

---
SHA-1: f879573ba3d8e62089b8c673257c928779f71692

Initial drop of code

---
master origin/master oms-phase4-v1.0.0
SHA-1: 56176dbe45e6175b18c9f44533828806c63142ab

OMS Phase 4 - Added OMS Cust. Order No. to EDI Purchase Order Header screens

Tag Info

object 56176dbe45e6175b18c9f44533828806c63142ab
type commit
tag oms-phase4-v1.0.0
tagger Richard Riviere <richard.riviere@myer.com.au> 1364338495 +1100

---
SHA-1: 0000000000000000000000000000000000000000

Working dir changes
0 files changed

---

代码肯定被推送到远程存储库.我已经能够通过将存储库克隆到不同的目录来进行检查.

有谁知道我收到的原因fatal: bad default revision 'HEAD'？

ps它是一个裸存储库但是我创建了其他没有这个问题的裸存储库.

Answer 1

当我正在处理的分支从存储库中删除时,这种情况发生在我身上,但我所在的工作区没有更新.(我们有一个工具,允许您使用simlinks从同一个存储库创建多个git"工作区".)

如果git branch没有将任何分支标记为当前分支,请尝试执行

git reset --hard <<some branch>>

我尝试了很多方法,直到我解决了这个问题.

Answer 2

只是做一个初始提交,错误将消失:

git commit -m "initial commit"

Answer 3

尚未承诺？

如果它没有提交,它是一个孤立分支.

Answer 4

您的回购是您的,在您推送或(允许)获取或克隆之前,其中发生的事情完全是您的业务.删除windows repo时 - 该文件夹不代表您的本地仓库,它是您的实际本地仓库,您删除了从未推送,获取或克隆过的所有内容.

编辑: 啊,好吧,我想我看到这里发生了什么:你推到了你的linux回购,但它不是裸露的,你从来没有参与其中.

而不是git log,做git log --all.或者git checkoutsome-branch-name.

然后尝试在Linux机器上本地克隆repo; 我打赌它有效.你用什么来为linux上的repo服务？尝试cd进入它的.git目录git daemon --base-path=. --export-all,如果只是坐在那里然后转到你的windows框并尝试git clone git://your.linux.box.ip,如果守护进程抱怨它无法绑定添加--port=54345到守护进程调用和:54345克隆网址.

Answer 5

注意:Git 2.6(2015年第3季度/第4季度)将最终提供更有意义的错误消息.

请参阅Jeff King()提交ce11360(2015年8月29日).^{(由Junio C Hamano合并- -在提交699a0f3,2015年9月2日)}peff
gitster

log:HEAD更清楚地诊断空虚

如果您初始化或克隆空存储库,则运行" git log" 的初始消息不是很友好:

$ git init
Initialized empty Git repository in /home/peff/foo/.git/
$ git log
fatal: bad default revision 'HEAD'

让我们检测一下这种情况并写一个更友好的消息:

$ git log
fatal: your current branch 'master' does not have any commits yet

我们还检测到'HEAD'指向一个损坏的ref的情况; 这应该更不常见,但很容易看到.
请注意,我们不会诊断所有可能的病例.我们依赖resolve_ref,这意味着我们无法获得有关复杂案例的信息.例如," --default master"将用于dwim_ref查找" refs/heads/master",但我们只注意到" master"不存在.
类似地,像" --default HEAD^2" 这样的复杂sha1表达式不会作为ref解析.

但那没关系.在这些情况下,我们会回到通用错误消息,并且它们不太可能被使用.
捕获空的或破碎的"HEAD"可以改善常见情况,而其他情况则不会消退.

Answer 6

确保分支"master"存在!它显然不仅仅是一个名字.

我创建了一个空白的裸仓库,将一个名为"dev"的分支推送到它,并尝试在裸仓库中使用git log时出现此错误.有趣的是,git branch知道dev是唯一存在的分支(所以我认为这是一个git bug).

解决方案:我重复了这个过程,这次在工作仓库中将"dev"重命名为"master",然后推送到裸仓库.成功!