在克服了学习Git的一些障碍后,我遇到了一个新的挑战:重命名目录(本地,在工作目录中)。
当我键入git status
时,它将旧目录名中的所有文件(与新目录中的文件名完全相同)列为deleted,新目录名列为“untracked”。
有没有办法告诉Git“这实际上是同一个目录,只是名称不同”?
所以所有的文件将被列为git status
作为修改只?
为了解决这个问题,下面是当我重命名整个目录时从git status
收到的输出:
git status
# On branch master
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# deleted: old-dir-name/file1
# deleted: old-dir-name/file2
# deleted: old-dir-name/file3
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# new-dir-name/
no changes added to commit (use "git add" and/or "git commit -a")
~/sb/ws>
字符串
5条答案
按热度按时间yvgpqqbh1#
只需要在新目录名下执行
git add
操作。Git不会显式跟踪重命名,它只是在以后检测它们。git mv
可能会稍微更有效(因为它可以直接更新索引),但效果是完全一样的。fcy6dtqo2#
这里的所有答案都对我所面临的特定场景的实际解决方案非常有帮助。我以实际步骤的形式提供了对我有效的方法,希望能帮助其他遇到同样挑战的人:
1.第一个月
git status
(验证所有标记为重命名的文件,而不是“已删除”的文件)git commit -a -m "git mv <old-dir-name> <new-dir-name>"
(这是一个“假”提交,为接下来的步骤中的真实的重命名做准备)git branch git_mv_20110708_1500_DO_NOT_USE
(“假”分支,带有时间戳,提醒我们这样做只是一种变通方法)/bin/rm -Rf <new-dir-name>
cp -Rp .../<new-dir-name> .
(复制重命名的文件夹)git status
(大多数修改过的文件现在将被正确标记为modified,而不是“deleted”。已重命名的文件将被标记为deleted * 和 * added,尽管内容相同!--如果这些文件也需要重命名跟踪,请重复步骤1-7)git add <untracked files>
个git commit -a -m "finally renamed this folder"
git branch FOLDER_RENAMED
:)P.S.
gitk
喜欢这个,但是Emacs
仍然与重命名混淆。b5lpy0ml3#
你需要使用git的mv:http://www.kernel.org/pub/software/scm/git/docs/git-mv.html
字符串
所以你需要把新的目录移回旧的目录,然后用mv重新移动它。
**编辑:**回答我的回答:
我决定自己测试一下。我创建了两个具有不同文本的文件,其中一个使用
git mv
,另一个使用mv file file2
,git add file2
,git add -u
。提交消息表明,这两个文件都被跟踪为重命名。因此,我的建议就是保存一个步骤,就像其他人说的那样。btqmn9zl4#
Git 2.18(Q2 2018)应该检测“这是同一个目录,只是名称不同”,因为“
git status
“学会了注意与UI相关的差异配置变量,如diff.renames
。参见commit dc6b1d9(2018年5月4日)Eckhard S. Maaß (``)。
(由Junio C Hamano --
gitster
--合并于commit 1e174fd,2018年5月23日)wt-status
:使用来自git_diff_ui_config
的设置如果你做一些类似的事情:
字符串
可以期望从X1 m5n1x和X1 m6n1x(或类似的与Diff-related程序)得到类似的输出。
通常情况下,情况并非如此,因为
git status
具有与diff相关的硬编码值。通过此提交,从status命令中删除硬编码设置,以支持
git_diff_ui_config
提供的值。以下是对
git status
中硬编码的具体选项的一些评论:型
从a3e870f中的
git status
开始(“Add“commit”helper script”,2005-05-30,Git v0.99),git status
总是使用重命名检测,而对于show和log这样的命令,必须使用命令行选项来激活它。在5404c11(“diff:activate
diff.renames
by default”,2016-02-25,Git v2.9.0)之后,默认值的行为是一致的,但是将diff.renames
更改为其他值可能会再次破坏git status
和其他命令之间的一致性。通过这个提交,一个控件与
diff.renames
具有相同的默认行为。型
类似地,
diff.renamelimit
选项可以调整除git status
之外的所有命令的限制。通过此提交,git status
也将荣誉这些命令。同样的Git 2.18也提供了
status.renames
,这对于那些不想禁用“git diff
“命令所做的默认重命名检测的人来说可能很有用。参见commit e8b2dc2(2018年5月11日)Ben Peart (
benpeart
)。(由Junio C Hamano --
gitster
--合并于commit 5da4847,2018年5月30日)添加重命名检测的状态配置和命令行选项
在执行有冲突的合并后,
git status
默认会尝试检测重命名,这会导致许多对象被检查。在一个虚拟化的仓库中,这些对象并不存在于本地,所以重命名逻辑触发它们从服务器获取。这导致在非常大的仓库上完成状态调用需要几个小时,而使用此补丁需要几秒钟。
添加一个新的配置
status.renames
设置,以便在状态和提交期间关闭重命名检测。此设置将默认为diff. renames的值。
添加一个新的配置
status.renamelimit
设置,以限制在状态和提交期间查找不准确重命名所花费的时间。此设置默认值为
diff.renamelimit
。将
--no-renames
命令行选项添加到状态,以便能够从命令行覆盖配置设置。添加
--find-renames[=<n>]
命令行选项到状态,使检测重命名和可选设置相似性指数。7gcisfzg5#
这个问题是一个用户界面/用户体验问题,而不是git的一个“真实的”问题。
实际上Git并不关心。所有你(我们)收到的消息都是关于'diff'认为可能发生的事情。使用其他选项,消息会有所不同,但仓库不会有任何不同(它是相同的快照!)。
一种选项样式是diff的
subtree
选项(尽管它的用途不同),--patience
也是如此。需要一个更好的UI/UX选项来更容易地检测路径变化(基于树而不是blob)。部分问题是Linus参数中的the subtle mistake。他是对的,Git repo应该不显式存储重命名(路径变化),而我们需要一个选项来允许它正确的发现。