Roger Leigh wrote:
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.
Then make it signed tags and ship them along.
Or do this properly and simply put in your buildsystem that some
targets never need to be rebuilt. That's (by far) the simplest
solution.
On a sidenote, I fail to see how the pre-generated stuff can avoid
getting updated unless also the sources for that stuff was updated,
in which case either of the following is true:
a) You really do need to rebuild, because upstream fucked up.
b) The pre-generated stuff should *also* be checked out and get new
timestamps.
Either way, to me it sounds like your buildsystem needs some love.
--
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
