Re: Git checkout preserve timestamp?

From: Bill Lear <rael@zopyra.com>
Date: Mar 5, 2007, 22:25 UTC
Message-ID: <17900.39124.763603.695942@lisa.zopyra.com>
In-Reply-To: <Pine.LNX.4.64.0703051347490.3998@woody.linux-foundation.org>

On Monday, March 5, 2007 at 13:50:45 (-0800) Linus Torvalds writes:

Show 10 quoted lines

>On Mon, 5 Mar 2007, Bill Lear wrote:
>> 
>> Not because git wrote the file, but because git notices that content
>> changes, and writes the file (and timestamps it) "smartly".  If
>> someone writes into the repo, the timestamp stored becomes invalidated
>> and the write of the file just creates the timestamp at the time of
>> the checkout.  If no write into the repo index occurs, the stored
>> timestamp is applied after the file is checked out.
>
>But Bill, don't you realize that restoring the timestamp is *WRONG*?

Maybe, maybe not. Each argument I've seen doesn't convince me. Sure, it may be MESSY. It may be UGLY, and therefore undesirable, but I don't think any of the arguments have conclusively shown that it is WRONG or INFEASIBLE in any way.

>There's no way that git can know whether you did a "make" in between 
>switching back and forth between branches. ...

Why should I care whether git knows this? I never said it should. As I said, if I have make products in separate, per-branch directories (a minor extension to my current make system), I don't see how this would be confusing in the least. Git should only care if the content of the file in the index changes. It shouldn't care in the least about my make products.

>                                      .... That's true on a very 
>fundamental level, but it's doubly true when anybody uses a separate 
>object directory (which doesn't leave any information *at*all* in the 
>source tree about the fact that somebody did a "make").

Here's the flow. Perhaps I'm fundamentally confused, and I'll be the first to admit that is true in plenty of ways:

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. I switch back to branchX, the file is checked out and stamped with timestamp M. I do a make. No recompilation happens. Happy happy, joy joy. If someone pushes into my repo, as Johannes suggested (how that would work, being a non-bare repo, is beyond me, but whatever), the timestamp for that file on that branch would be invalidated, and the file would get whatever timestamp it got when it was written to disk.

Now, all of this may be DISTASTEFUL, UGLY, POOR DESIGN, etc., but I don't see how it is WRONG. As someone who has professed the motto "actually useful is a lot better than clean, but not as useful", I fail to see what has gotten you so exercised about this.

Show 5 quoted lines

>So stop even asking for this. We'd have to be totally and utterly 
>incompetent to do what you ask for. We're simply not that stupid. 
>
>We already pointed out how you can do what you want to do *other* ways 
>that are *not* idiotic and incompetent. I don't think you even answered.

I am not asking for this, I'm just arguing the point, waiting for a convincing argument rather than having someone call me "idiotic and incompetent" and "stupid" for asking for it in the first place and carrying on in the spirit of discovery and open learning.

For your information, I did in fact answer, politely, thanking the poster for pointing our hash-based "stamps" that could do this sort of thing. I downloaded the software pointed to and tried it out, unsuccessfully, as it will require redoing our make system (not that I'm opposed to that, just that it will take time).

So ... thanks.

Bill