On Tue, Mar 11, 2014 at 4:42 PM, Graham Bloice
<graham.bloice@xxxxxxxxxxxxx> wrote:
> On 11 March 2014 20:35, Evan Huus <eapache@xxxxxxxxx> wrote:
>>
>> On Tue, Mar 11, 2014 at 2:01 PM, Roland Knall <rknall@xxxxxxxxx> wrote:
>> > Git commit ids differ
>> > between different people (each clone may create their one)
>>
>> Not technically true. If I make a commit with SHA x, push it, and it
>> gets submitted, then it is true that the final SHA in master will be y
>> != x. However, the next time I pull then I will get SHA y as well.
>> They x and y technically reference different commits, since y contains
>> additional information about who reviewed it, when it was submitted
>> from Gerrit, etc.
>>
>
> But aren't we talking about users, rather than devs? Users will either
> build from a clone from the main repo, or use an automated build, thus their
> reference point will be the Gerrit | master SHA whichever is the most
> appropriate name for it.
>
> In any case I don't think this fulfils the initial question. Previously we
> could say to users that an issue was fixed in svn r nnnn and they would
> "know" that any rev later than that was good. I don't understand how they
> can "know" that with a SHA of the latest master commit | merge.
SHAs aren't ordered like SVN revisions are (so given two arbitrary
SHAs and nothing else I can't determine which came first) but they do
still have an ordering in the repository.
Regardless, we can say: fixed in commit SHA. They can pull, and if
"git show SHA" shows the revision then they've got it. Otherwise they
don't.
