From: Andreas Ericsson <ae@op5.se>
To: Roger Leigh <rleigh@codelibre.net>
Cc: Christian MICHON <christian.michon@gmail.com>, git@vger.kernel.org
Subject: Re: git and mtime
Date: Thu, 20 Nov 2008 14:06:13 +0100 [thread overview]
Message-ID: <492560C5.5070308@op5.se> (raw)
In-Reply-To: <20081120112708.GC22787@ravenclaw.codelibre.net>
Roger Leigh wrote:
> On Wed, Nov 19, 2008 at 05:18:16PM +0100, Christian MICHON wrote:
>> On Wed, Nov 19, 2008 at 12:37 PM, Roger Leigh <rleigh@codelibre.net> wrote:
>>> Would it be possible for git to store the mtime of files in the tree?
>>>
>>> This would make it possible to do this type of work in git, since it's
>>> currently a bit random as to whether it works or not. This only
>>> started when I upgraded to an amd64 architecture from powerpc32,
>>> I guess it's maybe using high-resolution timestamps.
>>>
>> beside the obvious answer it comes back often as a request, it is
>> possible in theory to create a shell script which, for each file
>> present in the sandbox in the current branch, would find the mtime of
>> the last commit on that file (quite an expensive operation) and apply
>> it.
>
> Surely this is only expensive because you're not already storing the
> information in the tree; if it was there, it would be (relatively)
> cheap?
No, it's because git is *snapshot* based and doesn't care about anything
but contents. Storing filestate information in the tree would be a
backwards incompatible change that would require a major version change.
Caring about meta-data the way you mean it would mean that
git add foo.c; git commit -m "kapooie"; touch foo.c; git status
would show "foo.c" as modified. How sane is that? Or should we introduce
a new concept for altered metadata only? "metafied"? So what do we do
when the next user whizzes along and wants support for full acl's? And
what do we do when Windows (or some other bizarre system) add some sort
of extension so we have to have different types of ACL support on both
systems? Kablooie and welcome to interoperability hell.
> You could even compare the old and new trees to see if you
> needed to touch a file at all.
>
We already do that by matching the SHA1 hash for the index entries.
Only content that is actually different between to branches are altered
upon checkout (which is why it's so damn fast when you're using topic-
branches properly).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
next prev parent reply other threads:[~2008-11-20 13:07 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-19 11:37 git and mtime Roger Leigh
2008-11-19 12:22 ` Matthias Kestenholz
2008-11-20 8:38 ` Andreas Ericsson
2008-11-20 11:20 ` Roger Leigh
2008-11-20 12:48 ` Andreas Ericsson
2008-11-20 13:12 ` Andreas Ericsson
2008-11-19 12:31 ` Johannes Schindelin
2008-11-19 12:37 ` Arafangion
2008-11-19 14:54 ` Matthieu Moy
2008-11-20 8:39 ` Andreas Ericsson
2008-11-20 10:34 ` Johannes Schindelin
2008-11-20 10:53 ` Matthieu Moy
2008-11-19 13:29 ` Jakub Narebski
2008-11-19 16:18 ` Christian MICHON
2008-11-20 10:35 ` Johannes Schindelin
2008-11-20 11:27 ` Roger Leigh
2008-11-20 13:06 ` Andreas Ericsson [this message]
2008-11-20 14:15 ` Roger Leigh
2008-11-20 14:50 ` Andreas Ericsson
2008-11-20 15:19 ` Roger Leigh
2008-11-20 15:33 ` Kyle Moffett
2008-11-20 15:37 ` Andreas Ericsson
2008-11-20 18:36 ` Matthias Kestenholz
2008-11-20 13:11 ` Randal L. Schwartz
2008-11-20 13:40 ` Roger Leigh
2008-11-20 17:59 ` Daniel Barkalow
2008-11-20 19:24 ` Joey Hess
2008-11-20 13:21 ` martin f krafft
2008-11-20 13:35 ` Roger Leigh
2008-11-20 13:59 ` martin f krafft
2008-11-20 15:56 ` Samuel Tardieu
2008-11-20 14:07 ` Johannes Schindelin
2008-11-20 14:22 ` Roger Leigh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=492560C5.5070308@op5.se \
--to=ae@op5.se \
--cc=christian.michon@gmail.com \
--cc=git@vger.kernel.org \
--cc=rleigh@codelibre.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.