threads / discuss / 299

keyword expansion

Subject: keyword expansion

## tl;dr

5 messages between Apr 25, 2005 and Apr 26, 2005.

replies: 4people: 4as markdown or json

Thomas Glanzmann· Apr 25, 2005, 00:23 UTC · lore

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
tony.luck@intel.com· Apr 25, 2005, 17:56 UTC · re: Thomas Glanzmann · lore

mod-times (was: keyword expansion)

Show 5 quoted lines
> 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
Thomas Glanzmann· Apr 25, 2005, 18:10 UTC · re: tony.luck@intel.com · lore

Re: mod-times (was: keyword expansion)

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
Geert Bosch· Apr 25, 2005, 18:13 UTC · re: tony.luck@intel.com · lore

Re: mod-times (was: keyword expansion)

On Apr 25, 2005, at 13:56, tony.luck@intel.com wrote:
Show 13 quoted lines
>> 	- 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
Linus Torvalds· Apr 26, 2005, 00:34 UTC · re: tony.luck@intel.com · lore

Re: mod-times (was: keyword expansion)

On Mon, 25 Apr 2005 tony.luck@intel.com wrote:
Show 5 quoted lines
> 
> 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

← back to recent threads