[haiku-development] Re: Git/Hg: some speed tests
- From: Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 5 May 2011 01:05:33 +0200
Hi,
2011/5/5 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> On Wed, 4 May 2011 21:42:03 +0200 Niels Sascha Reedijk
> <niels.reedijk@xxxxxxxxx> wrote:
>> I would like to remind you of the following. The branchy nature of
>> hg/git means that revision numbers are not always chronological in
>> time. Say on haiku-central there is revision 10...15.
>>
>> haiku-central: 10 - 11 - 12 - 13 - 14 - (15)
>>
>> nielx: 10 - 11 - 12 - 13 - 14
>>
>> Now I made a local commit from revision 14 (which is my [15]), which
>> was made before haiku-central revision 15.
>>
>> nielx: 10 - 11 - 12 - 13 - 14 - [15]
>>
>> I pull in the the revision 15 from haiku-central, which will then
>> become my 16, and I create merge revision 17.
>>
>> nielx: 10 - 11 - 12 - 13 - 14 - [15] - 17
>> \ (16) /
>>
>> I push my 15, plus 17 back. 15 will become 16 in haiku-central, and 17
>> will remain 17. But this also means that revision 16 is older than
>> revision 15.
>>
>> haiku-central: 10 - 11 - 12 - 13 - 14 - (15) - 17
>> \ [16] /
>>
>> So in any case, having persistent tags will not always mean that 16 is
>> newer than 15.
>
> I tried to reproduce the situation with git, but regardless of the commit
> order I always end up with the merge commit on top. E.g. (3 repositories):
>
> central: 1
> a: 1
> b: 1
>
> Change and commit in b:
>
> central: 1
> a: 1
> b: 1 - 2b
>
> Change and commit in a, plus push to central:
>
> central: 1 - 2a
> a: 1 - 2a
> b: 1 - 2b
>
> Pull from central in b:
>
> central: 1 - 2a
> a: 1 - 2a
> b: 1 - 2b - 2a - merge
>
> Push to central from b and pull from central in a:
>
> central: 1 - 2b - 2a - merge
> a: 1 - 2b - 2a - merge
> b: 1 - 2b - 2a - merge
>
> When committing 2a before 2b those are swapped in the end result. Though I
> find this result more interesting with respect to revision number tags. I
> assume the result would be:
>
> central: 1 - 2b - 2a - merge
> tags: r1 - r3 - r2 - r4
>
> Right?
Well, I think you shouldn't understand the commits as having swapped.
2a and 2b are parallel revisions, so 1 - 2b - 2a - merge is the same
as 1 - 2a - 2b - merge. The only revision you can be certain about, is
the highest revision, because that is invariably the HEAD. However,
any revision between HEAD and revision 0 cannot be said anything of
meaning without checking the contents.
N>
Other related posts:
