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

Hello,

as probably many of you know CVS supported some magic tags which were replaced in committed files to a predefined value. For instance, if there was a "$Revision$" string in a file it would get replaced with "$Revision: x.y $" (or "$Revision: x.y.z.w $" and so on) where "x.y" is file's revision number.

Now, what I need is such feature in GIT. Upon committing I would like some magic string (say "$Date$") to be replaced with some value identifying uniquely given version of a file (a date of the commit would be sufficient).

I tried using some hooks for it but couldn't came up with anything that would actually work.

On Mon, Nov 10, 2008 at 01:22, Michal Nazarewicz <mina86@tlen.pl> wrote:

Please have a look at the relevant entry in the faq [0].

[0] http://git.or.cz/gitwiki/GitFaq#head-4a0afe71a2bb7734777a8b0b345e0308aefdbd40

"Sverre Rabbelier" <alturin@gmail.com> writes:

Thanks for the quick reply (and yes, I can't believe I couldn't find that myself...) but it still lacks one thing that I'd like to have. 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 ;) ).

Hi,

On Mon, Nov 10, 2008 at 6:46 AM, Michal Nazarewicz <mina86@tlen.pl> wrote:

I have worked on this topic quite a bit to fix issues in git-p4. There is no direct way to get this $Id$ expansion in git, however you can use a simple pre-commit hook (alpha state, more a proof of concept that happens to work for me)

#!/usr/bin/env bash

for file in `git diff-index --name-only --diff-filter=AM HEAD` ; do
        perl -pi -e 's/(\$[ \t]*Id)(.*)([ \t]*\$)/"\$Id: git
".time()." \$"/e' ${file}
        git add ${file} > /dev/null
done

-dhruva

dhruva <dhruvakm@gmail.com> writes:

In fact the following works just as well:

#v+ files=$(git diff-index --name-only --diff-filter=AM HEAD) perl -pi -e 's/\$\s*Id.*?\$/\$Id: git '$(TZ=UTC date +%s)' \$/g' $files git add $files #v-

But then again, it has two unpleasant side effects: (i) all modified files are added and (ii) if I abort a commit the file stays modified. (i) can be fixed by removing "git add" but then again (iii) even files which are not committed will be modified.

Michal Nazarewicz schrieb:

Just FYI: The $Id$ that git produces is completely different from what CVS produces and probably not what you expect: 'man gitattributes'

-- Hannes

Hi,

On Mon, 10 Nov 2008, Michal Nazarewicz wrote:

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).

If that is not your use case, then it may be wise to let us Git people know what you _actually_ want (i.e. instead of asking for a specific solution, you could tell us what your problem is).

Ciao, Dscho

Hi,

On Mon, Nov 10, 2008 at 5:55 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Since you have opened this topic to make a request with the problem, I have a problem for which I need $Id$ expansion.

The git-p4 tool does not record contents in $Id$. When I try to submit from git to p4 using git-p4, it does a 'p4 sync' which brings in modified files with $Id$ changes. When git-p4 tries to apply patches, it would not have recorded the change in $Id$. If there was a mechanism to make $Id$ change and tracked in git, it would have recorded a change as a hunk and the patch would have applied cleanly. I have posted this problem earlier and also on the #git channel. Hope to see some traction.

with best regards, dhruva

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

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.

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

"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...

Michal Nazarewicz <mina86@tlen.pl> writes:

Well, there is `ident` attribute which you can set in .gitattributes file which would make git do $Id$ keyword expansion. However the $Id$ git uses is not something you are familiar with: it is 40-character hexadecimal blob object name. With it you can find (try to find) relevant commit.

The reason why git doesn't support keywords like $Revision$ or $Date$ is performance: the $Revision$ and $Date$ are keywords related to _commit_ data, not blob data. You can have the same contents of the file in two different branches, thus two different commits, thus two different $Revision$ or $Date$. If contents of file didn't change between branches, git doesn't touch the file, which results in much faster branch switching, for example (and also faster committing).

What you can do is one of the following things:

1. You can try to use either hooks (post-commit, post-update I think)
   or smudge / clean filters (via gitattributes) to do keyword
   expansion. This hits performance, and you probably would have the
   problems CVS ad with keyword expansion.

2. You can use `export-subst` gitattribute and make git-archive do
   keyword expansion, which can include things like '$Format:%aD$'
   for commit date (equivalent of $Date:$?).

3. You can run some local equivalent of GIT-VERSION-GEN script git
   and Linux kernel uses, and make your build system (Makefile)
   replace '@@VERSION@@' or '++VERSION++' keywords / placeholders
   as part of compiling process.

HTH

Jakub Narebski <jnareb@gmail.com> writes:

In my case identifying content not commit would be even better.

Earlier in the thread there was following code for a pre-commit hook mentioned:

#v+ files=$(git diff-index --name-only --diff-filter=AM HEAD) perl -pi -e 's/\$Id.*?\$/\$Id: '$(TZ=UTC date +%s)' \$/g' $files git add $files #v-

Now, this meats all my needs except that (i) it adds all the files that were modified (ie. makes `git commit` work like `git commit -a`) and (ii) it modifies files even if the commit was aborted.

So, it seems that, what I need is: (i) a pre-commit-post-message-hook and (ii) a way to get a list of files that are being committed.

That would work but the thing is I'd like to have visioning without the need of creating releases or doing some other voodoo magic -- simply `scp file remote:file` or attach to an email.

Dnia poniedziałek 10. listopada 2008 18:38, Michal Nazarewicz napisał:

Well, in that case using `ident` attribute would be enough (but cryptic).

 # set `ident` attribute for all files
 $ echo '* ident' > .gitattributes

 # check that it is set for file 'foo'
 $ git check-attr ident -- foo
 foo: ident: set

 # edit file to contain '$Id$' keyword
 $ cat foo
 ...
 ... $Id$ ...
 ...

 # make a commit
 $ git commit -a

 # $Id$ keyword is replaced on checkout
 $ git add foo
 $ git checkout foo

 # and check that it got replaced
 $ cat foo
 ...
 ... $Id: 0ca1524d4460ba6bc91bf3adc9dab13212599243 $ ...
 ...

But you need git to make use of this SHA-1 _blob_ (contents) identifier

Jakub Narebski <jnareb@gmail.com> writes:

Yes, but it forces me to do some voodoo magic (ie. checkout) to get the Id in the file, ;) like so:

#v+
$ echo '$Id$' >bar && git add bar && git commit -m 'Added bar' && cat bar
Created commit d49d436: Added bar
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 bar
$Id$
$ rm bar && git checkout bar && cat bar
$Id: 055c8729cdcc372500a08db659c045e16c4409fb $
#v-

But never mind, since it seems hard to accomplish in git, I'll have to learn to live without it. ;)

Michal Nazarewicz wrote:

Well, _some_ command has to be invoked to expand keywords. "git add" doesn't do that (perhaps it should?), so you need to use checkout.

And checkout doesn't touch file if it is identical, so you need to remove it first; nevertheless you don't need to use commit in betwen, as "git checkout bar" would checkout file out of index (you added contents of file to index with "git add bar").

Le Monday 10 November 2008 21:17:29 Jakub Narebski, vous avez écrit :

If "git add" aims to do that, you'd have to be very, VERY careful, not to substitute in the wrong place to start with, not to attempt substitution in binary files...

And this would have a sizeable cost, imho. If you really want to do this, isn't there a hook somewhere that can do that for you, instead of modifying git add directly?

Dnia poniedziałek 10. listopada 2008 21:24, Francis Galiegue napisał:

If I remember correctly there was idea to add 'pre-add' or 'post-add' hook...

On Nov 10, 2008, at 3:32 PM, Jakub Narebski wrote:

Without adding any additional hooks, you could use the post-commit hook to look for any added/changed files containing $Id$ lines and force a checkout of them.

Perhaps something as simple as the following in your .git/hooks/post- commit (untested, caveat emptor, YMMV):

git diff --name-only --diff-filter=AM HEAD^ HEAD | \
while read file; do
   rm "$file" && git checkout -- "$file"
end

~~ Brian