On 30 June 2013 21:56, Fred Cooke <fred.co...@gmail.com> wrote: >> >> OK, so what is the Git command to download a copy of the sources that >> > are part of the hash? >> > > git checkout <hash>
Does not work for me. I get the following error message: fatal: Not a git repository (or any of the parent directories): .git This suggests that Git does not know where to download the hash from. > 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. Again I disagree; the reviewer should have the specific information they need without having to look elsewhere. And likewise it should be in the e-mail thread for historical purposes. > >> 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. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org