Re: git and mtime

[Roger Leigh <rleigh@codelibre.net>]

On Thu, Nov 20, 2008 at 03:50:49PM +0100, Andreas Ericsson wrote:
> 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.
>>>>>>
>>> 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.

The cost is tiny.  The extra space would be smaller than a single
SHA1 hash.

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

And yet the fact that it won't propagate makes it totally useless:
all the other people using the repo won't get the extra metadata
that will prevent build failures.  Having the extra data locally
is nice, but not exactly what I'd call a solution.  The whole point
of what I want is to have it as an integral part of the repo.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.