Re: RCS keyword expansion

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Peter,

please do not play games with the To: header.  We have a policy here 
(which is supposed to be good netiquette) that we keep people in the Cc: 
list that we respond to.

On Fri, 12 Oct 2007, Peter Karlsson wrote:

> Johannes Schindelin:
> 
> > The problem is this: for efficiency, git does not change files which 
> > have not changes between the last version checked out (whatever that 
> > is) and the current version.
> > 
> > This seems counterintuitive to people coming from SVN/CVS: they expect 
> > _every_ file to be touched when checking out.
> 
> No? That would just be strange. Only the files that are actually changed 
> should be updated, no others. A $Date$ or $Id$ will show the last 
> time/commit that specific file was changed, not the latest global state 
> (I guess the fact that most modern VCSs have global state makes this a 
> bit more difficult to achieve, in RCS/CVS/PVCS and others the change 
> history is local to a file and thus it is trivial to find the large 
> change for that particular file).

But don't you see?  When switching branches, this totally breaks down.  
No, really, IMHO it is enough to show either the commit name or the blob 
name of the file.  After all, you are not interested in the date that this 
file was last committed, but in the _contents_.

So why not go for the contents?  With CVS/SVN you only have the chance to 
do that by date or version number.  With git, we have a more powerful way: 
we do it by a hash of the contents.

> > As Randal already suggested: if you need something like this, you 
> > better have a build procedure which replaced $Date$ _at a given time_ 
> > (make install) with the current date.
> 
> But that's not what I want. Then my build procedure would need to do a 
> "git status", or whatever you use to get the last commit information 
> about a file, on each file that is changed and is to be installed. It 
> would be a lot easier if that was done already on checkout through some 
> kind of hook.

If it's not what you want, I suggest rethinking what you want ;-)

Otherwise it is scripting time for you.  It's easy enough with git.

Ciao,
Dscho