maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Cooke <>
Subject Re: Release process updates (try 2)
Date Sun, 30 Jun 2013 20:56:01 GMT
> 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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message