2015-07-18 56 views
3

实际上我没有重命名,我用linux rm删除了hash.c,然后从另一个目录复制了我的散列表实现的新版本hashdic.c与linux cp。删除的文件和新文件非常相似,但不一样,因为我在另一个目录中工作了hashdic.c几个小时。Git如何知道当我没有,但打算如何重命名文件?

然后,我输入git rm hash.c(尽管它已从文件系统中删除以便从存储库中删除),然后键入git add hashdic.c

Then git commit -am "update to hash table"。还有魔法! Git说:

renamed: hash.h -> hashdic.h 

但是,福尔摩斯,怎么样?如何从技术上将git删除并在不同名称下添加新文件?


全过程:从~/project/hash.c~/other/project/hashdic.c

  • 编辑〜/其它/项目/ hashdic.c

    • 复制/粘贴
    • rm hash.c
    • cp ~/other/project/hashdic.c ~/project/hashdic.c
    • git rm hash.c
    • git commit -am descr
  • 回答

    3

    试试这个:

    $ git diff --name-status -M HEAD^ HEAD 
    

    你应该看到的是,两次提交之间,这个文件被改名,并有一个 “相似性指数”(说)95:

    R095 hash.c hashdic.c 
    

    (我根据你的发帖输入了这一行 - 一行呼叫.h,其他人称之为.c,我在这里用.c去了;无论如何,它不会被剪切粘贴,所以可能会有一些小毛病 - 我弥补了相似指数值。但是,输出应该足够类似以识别,无论如何,我指望相似指数低于100%。显然至少有50%,因为这是默认设置。)

    这表明在之前和当前的提交之间,文件被重命名和修改了一下。

    一旦你做到了这一点,试试这个:

    $ git diff --name-status -M100% HEAD^ HEAD 
    

    这个时候,你应该看到,hash.c已被删除,hashdic.c加入:

    D  hash.c 
    A  hashdic.c 
    

    这表明之间的变化先前和当前提交已有重命名,只有已删除的文件和已添加的文件。

    这是什么?这是两个:这是一个地板蜡一个甜点顶部!事实上,git动态地计算提交(或提交和索引或工作目录,或任何这样的配对)之间的变化,每次你要求它,你是运行一个明确的git diff,还是运行git status(或者运行git statusgit commit为你运行)。您可以指定是否允许重命名检测(--no-renames ),如果是,则指定相似度阈值(-M)。

    您也可以要求复印检测(-C--find-copies-harder)。有多少“树名”可以应用这个限制,因为从计算的角度讲,可以通过比较每个文件中的每个文件和另一个文件中的每个文件来计算非常昂贵的代价。默认情况下,git限制你重命名检测,这比git更容易一些,因为git只对“在开始提交但不在目标中的文件名,vs在目标提交但不在开始的文件名”。除非你删除和/或添加额外的路径,所以git只需要将这两个文件相互区分,而不是针对任何其他文件,以获得单个相似索引和比较,为-M设置)


    大部分控制旋钮仅提供git diffgit status硬连线重命名检测到“开”和50%,例如。放入重命名检测队列的文件名的数量由git config设置控制,diff.renameLimit。其他的git命令,如git blame,可以通过用户可设置的控件运行git的内部diff引擎,但并不是所有这些命令都与git diff中的含义相同。例如,git blame只查看一个文件,而不查看整个目录,因此它的-C-M完全不同。