Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I am not sure this would be appropriate for a DVCS (as in "Distributed" VCS)</p> <p>The huge discussion had already took place in <a href="https://web.archive.org/web/20120518150852/http://kerneltrap.org/mailarchive/git/2007/3/5/240536" rel="noreferrer">2007 (see this thread)</a></p> <p>And some of Linus's answer were not too keen on the idea. Here is one sample:</p> <blockquote> <p>I'm sorry. If you don't see how it's WRONG to seta datestamp back to something that will make a simple "make" <em>miscompile</em> your source tree, I don't know what defintiion of "wrong" you are talking about.<br> It's WRONG.<br> It's STUPID.<br> And it's totally INFEASIBLE to implement.</p> </blockquote> <hr> <p>(Note: small improvement: <strong>after a checkout, timestamps of up-to-date files are no longer modified</strong> (Git 2.2.2+, January 2015): <a href="https://stackoverflow.com/a/28256177/6309">"git checkout - how can I maintain timestamps when switching branches?"</a>.)</p> <hr> <p>The long answer was:</p> <blockquote> <p>I think you're much better off just using multiple repositories instead, if this is something common.</p> <p>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 <em>enough</em> instead of recompiling <em>too much</em>.</p> <p>Git does make it possible to do your "check the other branch out" thing very easily, in many different ways.</p> <p>You could create some trivial script that does any of the following (ranging from the trivial to the more exotic):</p> <ul> <li><p>just create a new repo:</p> <pre><code>git clone old new cd new git checkout origin/&lt;branch&gt; </code></pre> <p>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.</p> <p>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.</p></li> <li><p>do the same thing with just a tar-ball instead, if you want to</p> <pre><code>git archive --format=tar --prefix=new-tree/ &lt;branchname&gt; | (cd .. ; tar xvf -) </code></pre> <p>which is really quite fast, if you just want a snapshot.</p></li> <li><p>get used to "<code>git show</code>", and just look at individual files.<br> This is actually <em>really</em> useful at times. You just do</p> <pre><code>git show otherbranch:filename </code></pre> <p>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)</p></li> <li><p>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 <em>all</em> your branches.</p></li> </ul> <p>and I'm sure any of the above are better alternatives than playing games with file timestamps.</p> <p>Linus</p> </blockquote>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload