Re: Git checkout preserve timestamp?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Mon, 5 Mar 2007, Bill Lear wrote:

> On Monday, March 5, 2007 at 13:50:45 (-0800) Linus Torvalds writes:
> >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.

It may not be infeasible.

But it is wrong. It "fixes" a totallc clear idiom, namely that every time 
a file is written into, the timestamp changes. And guess what, "touch 
<file>" is the best proof that sometimes, you want that this happens, even 
if the content stays the same.

> If someone pushes into my repo, as Johannes suggested (how that would 
> work, being a non-bare repo, is beyond me, but whatever),

Of course this works. That is a fundamental feature of Git: if you strip a 
non-bare repo of its working directory, then it becomes a bare repo.

> 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.

This approach is so fragile! It is invasive, easy to get wrong (count the 
ways how to invalidate the timestamp), and serves only an obscure use 
case, which is better solved otherwise to begin with.

> >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. 

FWIW I have to agree here. I saw quite a few projects go wrong, because 
management insisted on abolishing a perfectly good design, just because 
they had this pet idea.

> >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.

No. This is not what Linus was referring to (unless I am really wrong 
here, which I refuse to believe).

We pointed out, in several ways, how much easier it is to create a 
throw-away working directory.

It is easy, robust, and can be done _right now_ with Git.

Ciao,
Dscho

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]