keyword expansion

keyword expansion

[Thomas Glanzmann]

Hello,
I am aware that keyword expansion is at the moment at the very bottom of
the todo list. However I need it. Has someone something ready to use? I
am looking for the following informations:

	- Time stamp of the last modification of a file
	- last Committer/Author of the file

What I want is a script which runs after an export that checks for
keywords in files and expands them using informations extracted out of
the tree.  I would be gratefull for any pointers/shell snippsets.

I just migrated my mutt vendor tracking tree to git and it works quiet
well. Thanks for all the effort!

Greetings,
	Thomas

mod-times (was: keyword expansion)

[tony.luck]

> I am aware that keyword expansion is at the moment at the very bottom of
> the todo list. However I need it. Has someone something ready to use? I
> am looking for the following informations:
> 
> 	- Time stamp of the last modification of a file

One way to do this would be to rip on some of the core fundamentals of GIT
and store the time that an object was created inside the object. E.g.

   blob size secs-since-1970 ...

Then "read-tree" could fill this into the cache, and checkout-cache could
set the mod-time on the file when it creates it, which would mean that you
could see the timestamp for a file simply by using "ls -l file".

I think we'd need some other justifications before this would stand any
hope of getting in though, since it makes such a huge incompatible change
to the basic GIT format :-)  Maybe queue the idea for GIT2.0?

-Tony

Re: mod-times (was: keyword expansion)

[Thomas Glanzmann]

Hi,


> > 	- Time stamp of the last modification of a file

> One way to do this would be to rip on some of the core fundamentals of GIT
> and store the time that an object was created inside the object. E.g.

I think I have nearly something finished. Using rev-tree, cat-file and
ls-tree -r written in perl.

>    blob size secs-since-1970 ...

I dislike the idea because of reasons Torvalds has already mentioned
when talking about file renames and cvs annotate. And it also would fit
only this special case.

Having a 'git export' with real timestamps would be fun, but when I
think it over I don't really need it. And if I need it it would be a
matter of 20 minutes. :-)

	Thomas

Re: mod-times (was: keyword expansion)

[Geert Bosch]

On Apr 25, 2005, at 13:56, tony.luck@intel.com wrote:
>> 	- Time stamp of the last modification of a file
>
> One way to do this would be to rip on some of the core fundamentals of 
> GIT
> and store the time that an object was created inside the object. E.g.
>
>    blob size secs-since-1970 ...
>
> Then "read-tree" could fill this into the cache, and checkout-cache 
> could
> set the mod-time on the file when it creates it, which would mean that 
> you
> could see the timestamp for a file simply by using "ls -l file".

Of course this negates the idea of content-based storage, since you
want two copies of the same content with different time-stamps to share
the same blob.

   -Geert

Re: mod-times (was: keyword expansion)

[Linus Torvalds]

On Mon, 25 Apr 2005 tony.luck@intel.com wrote:
> 
> One way to do this would be to rip on some of the core fundamentals of GIT
> and store the time that an object was created inside the object. E.g.
> 
>    blob size secs-since-1970 ...

You really don't want that.

The thing is, somebody doing a "touch" on a file should _not_ cause that 
tree to be committed as a new tree.

Trying to save mtime in a git archive is about a million times worse than 
saving the whole "mode" information, and there we already ended up cutting 
it down to just one bit, exactly because it was horrible not to.

So this is not about git formats, this is about it just not being 
practical to do. Git simply isn't a good thing to store mtime in.

			Linus