Re: Git and ident of binaries

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Jan 12, 2010 at 11:56:43PM +0000, Thomas Adam wrote:
 > > What do we really want to know when we use ident on a binary to see what
 > > it was built with? The filename of each source file used to build it
 > > (which list is incomplete in our current system--e.g., we don't know the
 > > version of the .h files), and the version of the commit?
 > 
 > That's the question you need to ask yourself, and people switching away from
 > different RCSes to a distributed one which doesn't have the equivalence
 > often the get confused as to why it's not there at all, or limited
 > functionality is, but it is not the same.  The reason Git doesn't need $Id$
 > expansion is because the content of the file matters a lot lot more than the
 > file itself, as content tends to shift, for instance.  Not only that but
 > when you consider the history of a commit and the files it contains, the
 > atomicity of a single file, as with CVS is not important at all in something
 > like Git.

That paragraph just... does not make sense, I'm sorry. Especially the
second half. Can you try again?

I'm aware that with whole-tree commits, the straightforward CVS-like
expansion of $Id$ would be the same (except for the filename) in every
file in the tree. However, I don't see why that makes it unnecessary
or vacuous if you have (like NetBSD and every other OS tree does) a
lot of different binary images built mostly from one or two source
files each. If you run 'ident /usr/bin/fsplit' it doesn't much matter,
at least for many purposes, whether the version string associated with
fsplit.c is unique to fsplit.c or tree-wide; it's just the version of
fsplit you have. Keyword expansion in SCM-managed files is just a
convenient way of getting that information into the fsplit binary. It
has some issues, but so do the alternatives.


(current-users pruned again)
-- 
David A. Holland
dholland%netbsd.org@localhost