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 e
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, t
tps://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
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, Jun
Hi Mark,
Sorry, I wasn't clear. I don't know *nix OSes much, but under Windows
(NTFS), we have 3 file time stamps for each file (Creation, Last Read and
Last Write). I think it would practical only to consider the last write
time.
I don't see any technical reason for not having it other the
e to be 100% right for all the
people all of the time.
- Original Message -
From: winserver2...@gmail.com
To: Git for human beings
Cc: philipoak...@iee.org
Sent: Monday, June 05, 2017 11:51 PM
Subject: Re: [git-users] Keeping Timestamps
Hi, Yes, I have seen this &qu
e.
>
> - Original Message -
> *From:* winser...@gmail.com
> *To:* Git for human beings
> *Cc:* philip...@iee.org
> *Sent:* Monday, June 05, 2017 11:51 PM
> *Subject:* Re: [git-users] Keeping Timestamps
>
> Hi, Yes, I have seen this "rant" but its no
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. I
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 g
t some 'irrelevant' metadata.
>> https://confluence.atlassian.com/bbkb/preserving-file-timest
>> amps-with-git-and-mercurial-781386524.html
>>
>>
>> There's a rant by Linus somewhere on that...
>>
>> https://web.archive.org/web/20120518150852/http
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,
11 matches
Mail list logo
