Re: ident hash usage question

[Eugene Sajine <euguess@gmail.com>]

> 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