[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Git and ident of binaries
On Wed, Jan 13, 2010 at 08:50:24AM +0900, Curt Sampson wrote:
> On 2010-01-12 17:19 +0000 (Tue), David Holland wrote:
> > > These days, my preference would be to kill [keyword expansion]. It
> > > makes me nervous that a checkout of a particular revision is not
> > > what's in the repository for that particular revision, but instead
> > > a modified copy whose particular modifications may change when the
> > > VCS software changes.
> > It is nonetheless desirable to be able to ident binaries.
> I agree that that would be nice.
> In git, it seems to me that this could be done with a pre-commit hook
> which would expand or change the $NetBSD$ tag appropriately just before
> commit, thus ensuring that the right thing is in the repository itself.
> But I see two issues with this:
> 1. We can't use the SHA-1 of the commit in the id because we don't
> know what that SHA-1 is is, and we can't determine the SHA-1 of the
> commit until after we set the id. I suppose we could use the author
> and date, which should be enough to identify the commit.
> 2. How do we make sure that everybody's using this hook in their own
> repos? Hooks don't get cloned when you clone a repo.
You distribute the hook as part of the repository and use a README file --
no, I am not being flippant, that's how this sort of thing gets managed in
> On the other hand, given that with Git the part of the ids that changes
> with the version is no longer a per-file thing but a per-commit thing
> (i.e., an entire checkout has the same version), perhaps a better way of
> approaching it might be to have the build system insert or expand the
> IDs. (It could look up the SHA-1 of the current checkout.)
"man gitattributes" -- Git has expansion for $Id$ placeholders, but it
happens at git *checkout* for the opposite reason you stated above --
attempting to do this at commit time is meaningless.
> 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
-- Thomas Adam
"It was the cruelest game I've ever played and it's played inside my head."
-- "Hush The Warmth", Gorky's Zygotic Mynci.
Main Index |
Thread Index |