Subversion 的“use-commit-times"相当于什么?对于 Git? [英] What's the equivalent of Subversion's "use-commit-times" for Git?

查看:31
本文介绍了Subversion 的“use-commit-times"相当于什么?对于 Git?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我需要本地系统和服务器上文件的时间戳保持同步.这是使用 Subversion 实现的,方法是设置 use-commit-times=true 在配置中使每个文件的最后修改时间是提交时.

每次我克隆我的存储库时,我希望文件的时间戳反映它们在远程存储库中上次更改的时间,而不是我克隆存储库的时间.

有没有办法用 Git 做到这一点?

解决方案

我不确定这是否适合 DVCS(如分布式"VCS)

大讨论已经在2007(见此线程)

Linus 的一些回答并不太热衷于这个想法.这是一个示例:

<块引用>

对不起.如果您不明白将日期戳设置回可以制作简单制作"的东西是错误的错误编译你的源代码树,我不知道错误"的定义是什么?你在说.
这是错误的.
这是愚蠢的.
而且完全无法实施.


(注意:小改进:签出后,不再修改最新文件的时间戳(Git 2.2.2+,2015 年 1 月):git checkout - 如何在切换分支时维护时间戳?".)


答案很长:

<块引用>

我认为您最好使用多个存储库,如果这是常见的.

<块引用>

处理时间戳一般是行不通的.它只是向您保证制造"以一种非常糟糕的方式感到困惑,并且没有重新编译足够而不是重新编译太多.

<块引用>

Git 确实可以让你检查另一个分支"事情很容易,有很多不同的方式.

<块引用>

您可以创建一些简单的脚本来执行以下任何操作(从简单到更奇特):

<块引用>

  • 只需创建一个新的存储库:

<块引用>

 git clone old new新光盘git checkout origin/

<块引用>

你来了.旧的时间戳在您的旧仓库中没有问题,您可以在新仓库中工作(和编译),而完全不会影响旧仓库.

<块引用>

使用标志-n -l -s";到git clone"基本上使这个瞬间.对于很多文件(例如像内核这样的大型存储库),它不会像仅仅切换分支那么快,但是拥有工作树的第二个副本可能会非常强大.

<块引用>

  • 如果你愿意,也可以只用一个焦油球来做同样的事情

<块引用>

 git archive --format=tar --prefix=new-tree/|(cd .. ; tar xvf -)

<块引用>

如果您只想要快照,这真的非常快.

<块引用>

  • 习惯于git show",只查看单个文件.
    这有时真的很有用.你只要

<块引用>

 git show otherbranch:filename

<块引用>

在一个 xterm 窗口中,然后在另一个窗口中查看当前分支中的同一个文件.特别是,这对于可编写脚本的编辑器(即 GNU emacs)来说应该是微不足道的,在那里应该可以基本上拥有一个完整的直接模式".对于编辑器中的其他分支,使用这个.据我所知,emacs git 模式已经提供了这样的东西(我不是 emacs 用户)

<块引用>

  • 在那个虚拟目录"的极端例子中事情,至少有人在为 FUSE 开发 git 插件,也就是说,您实际上可以让虚拟目录显示所有您的分支.

<块引用>

而且我确信以上任何一种方法都是比玩带有文件时间戳的游戏更好的选择.

<块引用>

莱纳斯

I need the timestamps of files on my local system and on my server to be in sync. This is accomplished with Subversion by setting use-commit-times=true in the configuration so that the last modified of each file is when it was committed.

Each time I clone my repository, I want the timestamps of files to reflect when they were last changed in the remote repository, not when I cloned the repository.

Is there a way to do this with Git?

解决方案

I am not sure this would be appropriate for a DVCS (as in "Distributed" VCS)

The huge discussion had already took place in 2007 (see this thread)

And some of Linus's answer were not too keen on the idea. Here is one sample:

I'm sorry. If you don't see how it's WRONG to set a datestamp back to something that will make a simple "make" miscompile your source tree, I don't know what defintiion of "wrong" you are talking about.
It's WRONG.
It's STUPID.
And it's totally INFEASIBLE to implement.


(Note: small improvement: after a checkout, timestamps of up-to-date files are no longer modified (Git 2.2.2+, January 2015): "git checkout - how can I maintain timestamps when switching branches?".)


The long answer was:

I think you're much better off just using multiple repositories instead, if this is something common.

Messing with timestamps is not going to work in general. It's just going to guarantee you that "make" gets confused in a really bad way, and does not recompile enough instead of recompiling too much.

Git does make it possible to do your "check the other branch out" thing very easily, in many different ways.

You could create some trivial script that does any of the following (ranging from the trivial to the more exotic):

  • just create a new repo:

    git clone old new
    cd new
    git checkout origin/<branch>

and there you are. The old timestamps are fine in your old repo, and you can work (and compile) in the new one, without affectign the old one at all.

Use the flags "-n -l -s" to "git clone" to basically make this instantaneous. For lots of files (eg big repos like the kernel), it's not going to be as fast as just switching branches, but havign a second copy of the working tree can be quite powerful.

  • do the same thing with just a tar-ball instead, if you want to

    git archive --format=tar --prefix=new-tree/ <branchname> |
            (cd .. ; tar xvf -)

which is really quite fast, if you just want a snapshot.

  • get used to "git show", and just look at individual files.
    This is actually really useful at times. You just do

    git show otherbranch:filename

in one xterm window, and look at the same file in your current branch in another window. In particular, this should be trivial to do with scriptable editors (ie GNU emacs), where it should be possible to basically have a whole "dired mode" for other branches within the editor, using this. For all I know, the emacs git mode already offers something like this (I'm not an emacs user)

  • and in the extreme example of that "virtual directory" thing, there was at least somebody working on a git plugin for FUSE, ie you could literally just have virtual directories showing all your branches.

and I'm sure any of the above are better alternatives than playing games with file timestamps.

Linus

这篇关于Subversion 的“use-commit-times"相当于什么?对于 Git?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆