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@xxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
