如何更改.gitattributes生效

时间:2018-02-06 12:04:53

标签: git attributes line-endings

我正在开展一个我们最近开始使用git的项目。设置从一开始就不完美,所以我在人们开始克隆/工作后设置了.gitattributes,我仍在对这个文件进行一些更改。

考虑以下设置...

Alice和Bob都克隆了“repo.git”,并且存储库包含文件/myproj/src/file.ending,其中\n为行结尾,即该文件不包含\r个字符。

他们也有.gitattributes,具有以下设置:

/myproj/src/file.ending -text

这告诉git file.ending不应被视为文本文件,因此不应进行行结束转换。

因此,Alice和Bob的工作树中的文件也以\n作为行尾。

现在,Alice对.gitattributes进行了以下更改:

/myproj/src/file.ending text

Alice希望此更改能够为她和Bob实施。

我现在知道的唯一方法是非常具有侵入性:

git rm --cached -r .
git reset --hard

我想避免两件事:

      
  •     Alice在实际测试之前必须提交她的`.gitattributes`文件(上面的重置将覆盖她的更改)。   
  •   
  •     Bob必须擦除他的索引和工作树才能获得更新。鲍勃不高兴。   

这样做的首选方式是什么?

3 个答案:

答案 0 :(得分:2)

通过"希望此更改生效",您是否意味着Alice希望工作副本切换到她和Bob的Windows风格的行结尾?那么第一个问题是,为什么Alice要对Bob的工作树中的内容负责?

如果新属性更好地描述了文件,那就这样吧; .gitattributes文件可以像任何其他文件一样进行编辑,测试和提交。

您建议让新属性生效的程序没有多大意义,原因有两个:

首先,你为什么要擦指数? text属性会影响索引与工作副本之间的关系。在您的示例中,它似乎是您需要更改的工作副本,而不是索引。

其次,你为什么要从索引中删除所有?只需要解决属性已更改的路径。

因此,在您的示例中,如果Alice想要在本地反映新属性,那么最需要的是

rm myproj/src/file.ending
git checkout -- myproj/src/file.ending

由于此过程不会覆盖.gitattributes文件,因此无需过早提交。

我不清楚鲍勃对你原来的手术究竟是什么让人不满意,所以我不知道这个让他更开心。也许他只是希望在他拉动时更新是自动的;虽然期望这样做并不合理,但我不确定它是不是因为git有效。

问题是如何检测到更改。在几乎所有情况下,如果git在合并或快进结束时更新工作树(例如完成拉动),则只需要比较旧提交和新提交的索引对象的哈希值判断是否有适用的变更。

例外情况是属性(或过滤器定义)是否发生变化 - 如上所述,它不会改变索引。但是这些条件相对较少,并且对它们的检查比几乎每次都正确的哈希检查更加昂贵,所以不要把每次比较的负担与主要是毫无意义的成本相提并论git允许当你知道自己做了某些事情时,你必须采取额外的措施。

所以如果这发生一次,那就让团队沟通吧。 "此路径的属性正在发生变化;您可能想要刷新受影响文件的工作副本。"

如果它会反复发生,我最好的建议是弄清楚为什么会一直发生并修复它。您可以尝试设置某种脚本自动化,甚至可以使用钩子来检测和解决属性更改;但它有很多复杂功能,可能会造成比修复更多的麻烦。

答案 1 :(得分:1)

您不必费劲重新设置(如果我正确理解了您在做什么)。

我的情况很相似。我在正在运行的项目中添加了.gitattributes。我需要gitattr来管理我拥有的文件和在线仓库中的文件。

# This will force git to recheck and "reapply" gitattributes changes.
git rm --cached -r .
git add -A

您的提交将重新添加您提到的所有.ending文件,并且您不会丢失任何更改。当然,鲍勃将不得不拉扯它。

答案 2 :(得分:0)

osse上的

irc://chat.freenode.net/#git给了我这种方法,并且效果很好:

git rm -r :/ && git checkout HEAD -- :/

如果您的树中有未提交的更改,这会抱怨。

似乎应该有更好的方法。