> If the project is already arranged to be compiled with decent automation, > I do not think you need any change to the workflow. > > You would have a version.cc file with > > static char program_version[] = "My Program " VERSION_STRING; > > in it, and teach the build procedure how to compile and link this file. > Something like: > > version.o: version.cc > $(CXX) -o $@ -DVERSION_STRING=\""$(git describe HEAD)"\" $? > Please, correct me if I'm mistaken and forgive me if I'm not correct in using C++ terms. Your solution proposes to have a version file which will carry the info about last state the program was built from. But as I understand in case of static linking the executable will get only obj files from a library, which are necessary and everything irrelevant will be thrown away by linker. In this circumstances the program comparing two executable will not notice any differences between let's say existing production and new development version of the executable. In case of several libraries linked this gets even worse. That's what their basis is for keywords expansion use. If there is no other solution in VCS terms how to understand which particular version of file has got linked to the executable except keywords expansion, then I'm talking about the way of reducing the amount of keywords expanded to a minimum - 1. If we can agree on this, then it seems that having the content/blob hash in the file $Id$ is enough to get any other relevant info about the file. At least by hash you can find the path added/modified. When the path is on hands you can easily realize the history for the file. It seems to me that using content hash will provide unique results enough to make conclusions, because the probability of having two files with same hash but different content is too low, and only scenario is to get the same hash is to get the absolute copy of the file, but such file existence is questionable... OTOH, Alex was right that there are situation where this is not working as expected from the first run: If the file was modified its blob hash is going to change, but there will be no entry with letter A in the log. So, if $ git log --no-abbrev --raw --all | grep "SHA-1 A" Returns empty string then, we should do that without "A". As I understand this *second* run should always return: 1. only one entry if this is latest hash - one path. Goal reached. 2. two entries if there was a change afterwards - One path. Goal reached 3. three entries if rename was committed separately and then renamed file was changed - two paths. Enough to make conclusion about the files. In any case the goal is to get the path as correct as possible and then proceed with matching and other stuff. Thanks, Eugene -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html