Unique Git coordinates (was: Release process updates (try 2))

[sebb <se...@gmail.com>]

On 30 June 2013 21:56, Fred Cooke <fr...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Unique Git coordinates (was: Release process updates (try 2))

[sebb <se...@gmail.com>]

On 30 June 2013 23:28, Stephen Connolly <st...@gmail.com> wrote:
> On Sunday, 30 June 2013, sebb wrote:
>
>> On 30 June 2013 21:56, Fred Cooke <fred.cooke@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)

This seems to be replying to the wrong thread.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Unique Git coordinates (was: Release process updates (try 2))

[Stephen Connolly <st...@gmail.com>]

On Sunday, 30 June 2013, sebb wrote:

> On 30 June 2013 21:56, Fred Cooke <fred.cooke@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-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

-- 
Sent from my phone