在Git仓库中切换分支时,在文件系统中修改的日期不会更改 [英] Date modified in file system does not change when switching branches in Git repo
问题描述
有人可以帮我理解为什么使用Git切换分支时,Mac OS文件系统中的修改日期不会改变?例如,我有一个名为test.txt的repo文件,它是Master和Test分支的一部分。
在主分支中,我编辑并提交文件,然后切换到Test分支。由于Git操纵文件系统,我期望在那一点上修改的日期将改变为活动分支中文件版本的修改日期。
你的期望不正确。 Git在提交时不会记录文件的时间戳。
此外,如果结帐操作要求Git检索文件的不同版本并将其复制到您的项目的工作树,您的操作系统将更新工作树中文件的时间戳,以反映系统时钟显示的当前日期和时间。
自己检查一下通过执行以下实验。
首先设置:
cd〜/ Desktop
mkdir git_test
cd git_test
git init
创建一个文件,开始跟踪它并创建第一个提交(在 master>
)。
touch README.md
git add README.md
git commit -m将README添加到项目中
现在用
<$ p检查 README.md
文件的时间戳$ p> ls -la
写下这段时间;在我的情况下,时间是19:00;我们称之为时间1。在这个阶段,至少等待60秒。然后创建并签出名为 other
的新分支:
git checkout -b其他
编辑 README.md
;例如:
printf这是项目的README \\\
> README.md
现在执行文件并创建第二个提交(在其他
):
git add README.md
git commit -m编辑自述文件
再次执行 ls -la
,然后写入向下时间戳 README.md
;在我的情况下,时间是19:02;让我们称之为time2。
在这个阶段,提交图(尝试 git log --graph --all --decorate < code $)应该如下所示:
* other,HEAD
|
* master
现在查看 master $ c $再次检查工作目录中README文件的时间戳。
git checkout master
ls -la
现在,与您所期望的相反, README.md
不是匹配time1,而是当前时钟时间。在再次检查其他
之前至少等待60秒,并检查时间戳:
git checkout other
ls -la
在这种情况下,你期望, README.md
的时间戳不匹配time2,而是当前的时间。
编辑:下面是一个较短的实验,演示Git不会将文件的时间戳烧入相应的SHA-1散列blob。
printfhello\\\
> greetings.txt
git hash-object greetings.txt
记下返回的散列值。等一下。
touch greetings.txt
git hash-object greetings.txt
尽管 touch greetings.txt
更改了 greetings.txt
在您的文件系统中,散列值应该与第一次调用 git hash-object
时相同。
Can someone please help me understand why when switching branches with Git that the modified date in the Mac OS file system does not change? For example, I have a file in repo called test.txt that is part of both the Master and Test branches.
In the master branch I edit and commit the file and then switch to the Test branch. Since Git manipulates the file system, I would expect at that point that the date modified would change to the modified date of the version of the file in the active branch.
Your expectation is incorrect. Git doesn't record a file's timestamp at the time of commit.
Moreover, if the checkout operation requires Git to retrieve a different version of the file and copy it to your project's working tree, your operating system will update the timestamp of the file in the working tree to reflect the current date and time shown by your system clock.
Check things for yourself by performing the following experiment.
First set things up:
cd ~/Desktop
mkdir git_test
cd git_test
git init
Create a file, start tracking it and create a first commit (on master
).
touch README.md
git add README.md
git commit -m "add README to project"
Now inspect the timestamp of the README.md
file with
ls -la
Write that time down; in my case, the time is 19:00; let's call that "time1". At this stage, wait for at least 60 seconds. Then create and check out a new branch called other
:
git checkout -b other
Edit README.md
; for instance:
printf "This is the project's README\n" > README.md
Now stage the file and create a second commit (on other
):
git add README.md
git commit -m "edit README"
Do ls -la
again, and write down timestamp of README.md
; in my case, the time is 19:02; let's call that "time2".
At this stage, the commit graph (try git log --graph --all --decorate
) should look as follows:
* other, HEAD
|
* master
Now check out master
again and inspect the timestamp of the README file in your working directory.
git checkout master
ls -la
Now, contrary to what you expect, the timestamp of README.md
does not match time1, but the current clock time. Wait at least another 60 seconds before checking out other
again and check the timestamp:
git checkout other
ls -la
Again in this case, contrary to what you expect, the timestamp of README.md
does not match time2, but the current clock time.
Edit: Here's a shorter experiment demonstrating that Git doesn't bake the timestamp of a file into the SHA-1 hash of the corresponding blob.
printf "hello\n" > greetings.txt
git hash-object greetings.txt
Write down the hash value returned. Wait a bit.
touch greetings.txt
git hash-object greetings.txt
Even though touch greetings.txt
changed the timestamp of greetings.txt
in your filesystemm the hash value should be the same as the first time you invoked git hash-object
.
这篇关于在Git仓库中切换分支时,在文件系统中修改的日期不会更改的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!