> > OK, so what is the Git command to download a copy of the sources that > are part of the hash? >
git checkout <hash> Then observe the tree. You can also export an archive, though I don't recall the exact command off the top of my hand. > Don't I need to know something about the Git repo it comes from? > Yes, the URL which would be pre-agreed. Providing it would be a nice convenience, but nothing more. > Or are Git hashes guaranteed to be universally unique? > Nothing is, however within the realms of SHA1 collisions, sure. The chances of finding a second repo for *any* other piece of software that contains the identical hash is pretty low. The chances of finding the same hash in a single Git repo is impractically low. I can't see how that is handled, but the obvious way would be to just respin the commit so the date meta data changed and the hash changed. In any case, if that's a flaw, it's a flaw of Git, and can't be avoided. In practice, it's not a flaw at all. > It's just sloppy not to do this; if a quality release process is required, > > so is the SVN rev number. If "good enough" is OK, then it can be omitted > > because you can, most of the time, just guess. Guessing = mistakes, > though. > > Sorry, I have to disagree there; the source reference cannot be > omitted under any circumstances because it's not possible to review > the source release without a reference to the files in SCM. There's no > way to determine provenance otherwise. > I was trying to be nice with "sloppy" or perhaps sarcastic. It's totally unacceptable to me, however it seems like some people here think it's OK. I can see their point of view, however it's too easy to do it right to justify not doing it right. I agree with you, completely. Fred.
