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.
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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
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
