On Sunday, 30 June 2013, sebb wrote: > On 30 June 2013 21:56, Fred Cooke <fred.co...@gmail.com <javascript:;>> > 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.
Until I hear otherwise, the reviewers for whom this is critical (ie the PMC) have enough context to figure out which repo the vote refers to. (Or they just look it up from the Pom in the source bundle) Now I am not saying that it is ideal, and given how easy it is to provide the details, I don't think it shoud be avoided, but when reviewing policy and procedure it is necessary to get to the root requirements so that the changed procedure (if it gets changed) is not doing things fr the sake of doing them... The fable of the fve chimpanzees and the ladder and the bunch of bananas is always relevant when reviewing procedures (every time a chip tries to climb the ladder, power-hose them all until it stops... Eventually no chimp will try to climb... Then start swapping out chimps one at a time.... Then stop hosing and end up with a room full of chimps who will beat the crap out f any chimp that tries to climb the ladder but they don't know *why*) > 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 <javascript:;> > For additional commands, e-mail: dev-h...@maven.apache.org <javascript:;> > > -- Sent from my phone
