git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: RCS keyword expansion

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Oct 12, 2007, 10:02 UTC
Message-ID
<Pine.LNX.4.64.0710121057540.25221@racer.site>
In-Reply-To
<Pine.LNX.4.62.0710120723480.11771@perkele.intern.softwolves.pp.se>
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:
Show 16 quoted lines
> 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.

Show 9 quoted lines
> > 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

Previous: Peter KarlssonNext: Peter Karlsson
Message 9 of 27 in “RCS keyword expansion”
  1. Peter KarlssonOct 11, 2007
  2. Johannes SixtOct 11, 2007
  3. Randal L. SchwartzOct 11, 2007
  4. Oliver KullmannOct 11, 2007
  5. Alex RiesenOct 11, 2007
  6. Johannes SchindelinOct 11, 2007
  7. Sam VilainOct 11, 2007
  8. Peter KarlssonOct 12, 2007
  9. Johannes SchindelinOct 12, 2007
  10. Peter KarlssonOct 12, 2007
  11. Johannes SixtOct 12, 2007
  12. Lars HjemliOct 12, 2007
  13. Johannes SchindelinOct 12, 2007
  14. Peter KarlssonOct 15, 2007
  15. Johannes SchindelinOct 15, 2007
  16. Jan HudecOct 12, 2007
  17. Salikh ZakirovOct 12, 2007
  18. Johannes SchindelinOct 12, 2007
  19. Zakirov SalikhOct 12, 2007
  20. Peter KarlssonOct 11, 2007
  21. Alex RiesenOct 11, 2007
  22. Peter KarlssonOct 12, 2007
  23. Barry FishmanOct 12, 2007
  24. Linus TorvaldsOct 12, 2007
  25. Florian WeimerOct 12, 2007
  26. Sam VilainOct 11, 2007
  27. Lars HjemliOct 11, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.