Re: git and mtime

[Andreas Ericsson <ae@op5.se>]

Roger Leigh wrote:
> On Thu, Nov 20, 2008 at 02:06:13PM +0100, Andreas Ericsson wrote:
>> 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.
> 
> It's not strictly true that it's only caring about contents.  The
> contents are of course in the blobs, but the tree is already
> effectively storing inode data, since it's a directory of
> filenames/subtrees, just one that only cares to store the
> permissions part of the total inode data.
> 
> I understand that git stored the permissions tacked onto the hash;
> would it be feasable to tack on the other bits as well.

No, that would break backwards compatibility with cross-repo
transfers.

> If I understand correctly, it's binary encoded in the pack format,
> and that would require updating the format to hold the additional
> data?
> 
>> 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?
> 
> I've never come close to suggesting we do anything so insane.
> 
> What I am suggesting is that on add/commit, the inode metadata
> be recorded in the tree (like we already store perms), so that
> it can be (**optionally**) reused/restored on checkout.
> 
> Whether it's stored in the tree or not is a separate concern from
> whether to *use* it or not.  For most situations, it won't be
> useful, as has been made quite clear from all of the replies, and I
> don't disagree with this.  However, for some, the ability to have
> this information to hand to make use of would be invaluable.
> 

Then write a hook for it. You agree that for most users this will be
totally insane, and yet you request that it's added in a place where
everyone will have to pay the performance/diskspace penalty for it
but only a handful will get any benefits. That's patently absurd.
Especially since there are such easy workarounds that you can put in
place yourself instead.

> 
> There have been quite a few suggestions to look into using hooks,
> and I'll investigate this.  However, I do have some concerns
> about *where* I would store this "extended tree" data, since it
> is implicitly tied to a single tree object, and I wouldn't
> want to store it directly as content.
> 

Store it as a blob targeted by a lightweight tag named
"metadata.$sha1" and you'll have the easiest time in the world when
writing the hooks. Also, the tags won't be propagated by default,
which is a good thing since your timestamps/uid's whatever almost
certainly will not work well on other developers repositories.

That's what I'd do anyways.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231