Re: [git-users] Keeping Timestamps

[Michael]

On 2017-06-06, at 7:31 PM, Maurizio Vitale  wrote:

> Everybody else manage without restoring the timestamps, so it would be 
> probably easier if you described what you want to achieve.

Here's the problem: Just because people "manage" without a feature doesn't mean 
the feature is wanted.

Heck, people managed without DVCS's/git for a while :-).

> Because when you clone a repository clearly the time of the last write is 
> when the files are written into your workspace. Pretending that is some other 
> date in the past has a usefulness that I fail to see. 
> Furthermore, do you really want to believe that a file is newer than it is 
> just because somebody (human or script) run touch (or similar)?

So you want use cases? Alright.

I routinely use the modified time of files (sadly, the only filetime I can rely 
on) to sort, to place a file in historical context, etc.

I'm on a system that has at least the following sets of times:
1. Unix C-time, when the inode was modified. But inodes are not the native file 
designation here.
2. Unix M-time, when the file was last modified. Except when it is not because 
not all file writes update this for some reason.
3. Unix A-time, which is useless most of the time because it is not updated, or 
because a system indexer reads everything anyways.
4. Hfs+ created, added-to-directory, modified, and last opened, which are not 
the same as the unix ones and are set by a number of things used in the real 
file system and not propagated out to the unix/posix system. Oh yea -- "last 
opened" isn't even set by posix things because they aren't real "apps".

Of these, Mtime is the most reliable. But ... well, it turns out that a 
memory-mapped file that is "written" to doesn't update mtime. [How significant 
was this? It broke ntp, because Apple set up a new system with "pacemaker", so 
that ntp would do less work, and give significant battery savings (pacemaker 
would only have to adjust things twice a second, I think was the default).]

Use cases? Relying on the time stamp to know the age of the file. Backup 
programs -- the good ones -- restore the timestamps of the files. Restoring a 
file out of a git archive is very similar to restoring a file from the backup.

---

Yes, for files that are being used for compilation, where you want the new file 
to be compiled, you want "now" so that things will be read and processed. 
But if you are looking at non-source data, "time" can matter.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Keeping Timestamps

[winserver2017]

On Monday, June 5, 2017 at 11:04:07 PM UTC-4, Michael Gersten wrote:
>
>
>
> Now, for data that has lost the "timestamp", is in a pack file, with no 
> recorded pack file? How about defaulting to the time of the earliest commit 
> that the file appears in? 
>


So there is a pack process?  If a git patch/update is done,  it should 
include pack as well.

--
HLS

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Keeping Timestamps

[Michael]

On 2017-06-05, at 4:39 PM, Philip Oakley  wrote:

> Hi, yes it can be awkward when different systems make different choices about 
> which feature they want to use as the indicator for what they really want to 
> look at. For git the sha1 object id (oid) is what tells you that it has 
> changed. Its unfortunate that the 'timestamp' concept is used elsewhere as it 
> doesn't really scale in a distributed architecture. My local time may be 
> different to yours, so if I restore a file that you saved then what should 
> happend to the time stamp. Should it be adjusted for time zone, for clock 
> drift, etc. Your stored file may be in the future relative to my system clock 
> which causes some systems to 'explode', etc.

Easy. Convert your local time to UTC; store the UTC time.

Clocks not set correctly? Fine, record the system inaccurate time. If your 
clock is not set right, there's bigger things to worry about than getting git 
to learn about inaccurate clocks :-).

... Commits record the timestamp of the commit, right? So git already knows how 
to work with UTC times. A "check-in" (add operation) doesn't record a time 
anywhere, *except the timestamp of the object in the git database*. So there is 
a time thingy in there, to be retro-collected. Except, you know, once it goes 
into a pack file. So ...

I think it makes good sense for git to record timestamps as of the time of 
"add" -- it is already recorded in the file meta data for the object, and it 
can be saved when copied into a pack file. Whether or not it makes sense to 
restore it when you check a file out is another thing, and that would be 
use-case dependent (as mentioned, for a compile environment, you want to force 
updates; for a data environment, you probably want the time of the data to be 
accurate.)

Now, for data that has lost the "timestamp", is in a pack file, with no 
recorded pack file? How about defaulting to the time of the earliest commit 
that the file appears in?

---
Entertaining minecraft videos
http://YouTube.com/keybounce

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Keeping Timestamps

[winserver2017]

Hi, Yes, I have seen this "rant" but its nonsense of course.   My small 
rant.   Just because it wasn't added, doesn't mean it was the proper to 
keep it out for what many would consider a natural design element for 
copying/moving files around.  As with most things, it could of been made 
optional. Keeping the timestamp(s) is as important as the content itself. 
 While it ruins build processes, especially complex dependencies,  imo, 
version control is being used more for documents in general, not just for 
source code. Keeping "snapshots" was always a part of the file history.  I 
personally have source/files all over the network. I am not about to "look" 
inside of it to see "differences."  Generally, the timestamp itself is 
sufficient.


Anyway, it would be a welcome "advancement" to GIT to be able to restore 
original file commited time stamp(s), at least the last write timestamp, 
not necessarily the creation and last read timestamps (Windows).

If I follow the database layout, the .git stored file time stamps "could" 
be used to save the Last Write during a commit and to restore it during a 
pull. Otherwise, some other record file/index would be needed.  That makes 
it more complex.

Maybe there could be "hooks" during the commit/pull for each file.   The 
hooks can keep the "extra database."

--
HLS

On Monday, June 5, 2017 at 5:58:14 PM UTC-4, Philip Oakley wrote:
>
> In general, No. It's contrary to the basic Git VCS view. it's the content 
> that matters not some 'irrelevant' metadata.
>
> https://confluence.atlassian.com/bbkb/preserving-file-timestamps-with-git-and-mercurial-781386524.html
>  
>  
> There's a rant by Linus somewhere on that...
>  
>
> https://web.archive.org/web/20120518150852/http://kerneltrap.org/mailarchive/git/2007/3/5/240536
>  
> Sorry.
>  
>
> - Original Message - 
> *From:* winser...@gmail.com  
> *To:* Git for human beings  
> *Sent:* Monday, June 05, 2017 10:31 PM
> *Subject:* [git-users] Keeping Timestamps
>
> Hi,  Is there an option or version of GIT with a database that keeps the 
> last file stamp of committed files??   
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Git for human beings" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to git-users+...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Keeping Timestamps

[Philip Oakley]

In general, No. It's contrary to the basic Git VCS view. it's the content that 
matters not some 'irrelevant' metadata.
https://confluence.atlassian.com/bbkb/preserving-file-timestamps-with-git-and-mercurial-781386524.html


There's a rant by Linus somewhere on that...

https://web.archive.org/web/20120518150852/http://kerneltrap.org/mailarchive/git/2007/3/5/240536

Sorry.

  - Original Message - 
  From: winserver2...@gmail.com 
  To: Git for human beings 
  Sent: Monday, June 05, 2017 10:31 PM
  Subject: [git-users] Keeping Timestamps


  Hi,  Is there an option or version of GIT with a database that keeps the last 
file stamp of committed files??   



  -- 
  You received this message because you are subscribed to the Google Groups 
"Git for human beings" group.
  To unsubscribe from this group and stop receiving emails from it, send an 
email to git-users+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Keeping Timestamps

[Mark Waite]

On Mon, Jun 5, 2017 at 3:31 PM  wrote:

> Hi,  Is there an option or version of GIT with a database that keeps the
> last file stamp of committed files??
>
>
It depends what you mean by "file stamp".

If "file stamp" means a cryptographically strong checksum of the contents
of the file, then yes, that is retained in all versions of git.

If "file stamp" means the time of the most recent commit, then yes, the
time of the most recent commit is recorded in the commit log by all
versions of git.

If "file stamp" means the names of the files included in the most recent
commit, then yes, that is recorded in the commit log by all versions of git.

If "file stamp" means that files have their create date or modify date (or
other date related attribute) set to the date of the most recent commit on
checkout of that file, then no, that is not done in any version of git.
Refer to
https://stackoverflow.com/questions/2179722/checking-out-old-file-with-original-create-modified-timestamps
for more details.

Mark Waite


> --
> You received this message because you are subscribed to the Google Groups
> "Git for human beings" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to git-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Keeping Timestamps

[winserver2017]

Hi,  Is there an option or version of GIT with a database that keeps the 
last file stamp of committed files??   

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.