Re: Git checkout preserve timestamp?

From: Bill Lear <rael@zopyra.com>
Date: Mar 5, 2007, 23:20 UTC
Message-ID: <17900.42415.750335.329874@lisa.zopyra.com>
In-Reply-To: <Pine.LNX.4.64.0703051431130.3998@woody.linux-foundation.org>

On Monday, March 5, 2007 at 14:37:15 (-0800) Linus Torvalds writes:

Show 13 quoted lines

>On Mon, 5 Mar 2007, Bill Lear wrote:
>> I edit sourcefile.c, compile it, then commit it with
>> N=timestamp(sourcefile.c) on master.  N is <
>> timestamp(.master/sourcefile.o).  I then switch to branchX.  N is
>> stored by git for master:sourcefile.c.  No stored timestamp are on
>> this branch, so the file gets the timestamp it gets on checkout
>> M=timestamp(sourcefile.c).  I compile the file again, all is well.  I
>> move back to master branch.  Git stores M as branchX:sourcefile.c Git
>> checks out the file, and stamps it with N.  I do a make.  No
>> recompilation happens.
>
>WHICH IS WRONG! You need to recompile, since the compile you did on the 
>other branch DOES NOT MATCH in "sourcefile.c" any more.

Well, I'll let it drop after this, but I think you're wrong. I do NOT need it to recompile when I do the third make above. The time stamps match up perfectly with the make products, the make system is NOT confused, the appropriate rebuilds occurs WHEN I want them to, and my make products are thereafter a model of wholesome sanity and blissful unity.

Again, this may be violating a sacred rule of "thou shalt not f~ck with timestamps", but I'm not religious on that point.

I share the desire of never getting make products when I should not, and appreciate the desire to never, ever, NOT recompile something when it must, which is what the above example does. I also understand there are better ways than having git do this with timestamps, it's just that I'm not understanding your logical argument, even with all caps emphasizing your points. Perhaps I'll build a prototype, have it blow up in my face, and then understand ...

>And if sourcefile.c _does_ match in the two branches, then git *already* 
>won't have changed it at all, so git already does the obvious 
>optimization.

I'll let this drop. It appears we are not communicating, which you seem to be translating and signaling (in all caps, no less) as "you are stupid". That's ok, I've felt that way about others from time to time, so I understand and sympathize with your frustration.

I do thank you (all) for pointing out the much less invasive alternatives, using git (right now) and still, despite this rather heated exchange, think git is a very cool and thoughtfully put together collection of software.

Bill