Re: Something like $Id$, $Revision$ or $Date$?

On Mon, 10 Nov 2008, Michal Nazarewicz wrote:

quoted

I would like the "$Id$" sequences to be updated automatically after a 
commit (ie. without the need to check out).  (Besides I would prefer 
$Date$ more but I can live with $Id$ I guess ;) ).

Johannes Schindelin [off-list ref] writes:

No, you don't.

At least most likely you do not want that behavior.  Typically, you have 
the $Id$ stuff in released versions to indicate what revision that version 
came from even if the files are no longer in a Git repository.

And you can have that without ever committing anything in-between, by 
using the export-subst attributes with git-archive.  Have a look at 
Documentation/gitattributes.txt (I agree it is underdocumented in 
git-archive.txt).

The thing is that for some repositories I don't distinguish anything
like a "release version" of files.  For instance, I have a repository
with my configuration files, and I want to be able to do

  scp emacs system-where-git-is-not-installed:.emacs

or attaching the file in an email without worrying about anything.
Instead, what you're describing would force me to do some voodoo magic
priory to sending the file.

-- 
Best regards,                                         _     _
 .o. | Liege of Serenly Enlightened Majesty of      o' \,=./ `o
 ..o | Computer Science,  Michal "mina86" Nazarewicz   (o o)
 ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--

Le Monday 10 November 2008 16:48:48 Michal Nazarewicz, vous avez écrit :
[...]

The thing is that for some repositories I don't distinguish anything
like a "release version" of files.

"Git tracks contents, not files".

You have two problems here:
* first, unlike CVS, files don't have revisions;
* second, unline SVN (or even Mercurial), commits are not "ordered", at least 
not in a natural way (can't tell what SHA1 is more recent).

Git will not track a single file, and I don't think it will ever do so. And 
then, what about renames?

You have two options there:

1. (requires git modification, I guess) put a $last_modified_date$ magic that 
expands to the last modification date;
2. (what I do) keep an internal ChangeLog for such files, that you (have to) 
fill by hand each time.

The second approach has big advantages:
* you can date your changes;
* you _really_ know the file history;
* git's renaming handle allows you to track this ChangeLog over time!

It requires discipline, though...

-- 
fge