Jakub Narebski writes:
> Jakub Narebski writes:
>> Stefan Beller writes:
> [...]
>>> How would this impact creation of a commit?
>>>
>>> The current generation numbers can be lazily updated or not
>>> updated at all. In my understanding of the maximum generation
>>> numbers, a new commit would
Derrick Stolee writes:
> On 11/1/2018 8:27 AM, Jakub Narebski wrote:
>> Derrick Stolee writes:
>>
>>> Please also let me know about any additional tests that I could
>>> run. Now that I've got a lot of test scripts built up, I can re-run
>>> the test suite pretty quickly.
>>
>> I would add
Derrick Stolee writes:
> On 10/31/2018 8:54 AM, Ævar Arnfjörð Bjarmason wrote:
>> On Tue, Oct 30 2018, Junio C Hamano wrote:
>>> Derrick Stolee writes:
In contrast, maximum generation numbers and corrected commit
dates both performed quite well. They are frequently the top
Derrick Stolee writes:
> On 10/29/2018 11:59 PM, Junio C Hamano wrote:
>> Derrick Stolee writes:
[...]
>>> * **Compatible?** In our test implementation, we use a previously unused
>>>byte of data in the commit-graph format to indicate which reachability
>>>index version we are using.
Jakub Narebski writes:
> Stefan Beller writes:
[...]
>> How would this impact creation of a commit?
>>
>> The current generation numbers can be lazily updated or not
>> updated at all. In my understanding of the maximum generation
>> numbers, a new commit would make these maximum generation
>>
Derrick Stolee writes:
> Here is a re-formatted version of the tables I introduced earlier.
> The tables were too wide for public-inbox to render correctly (when
> paired with my email client). Hopefully this bulleted-list format
> works better. Thanks, Stefan, for pointing out the rendering
>
Stefan Beller writes:
>> Based on the performance results alone, we should remove minimum
>> generation numbers, (epoch, date) pairs, and FELINE index from
>> consideration. There are enough examples of these indexes performing
>> poorly.
>>
>> In contrast, maximum generation numbers and
On 11/1/2018 8:27 AM, Jakub Narebski wrote:
[I have noticed that in some places I wrote A..B instead of B..A. Sorry
about that]
Derrick Stolee writes:
Please also let me know about any additional tests that I could
run. Now that I've got a lot of test scripts built up, I can re-run
the
[I have noticed that in some places I wrote A..B instead of B..A. Sorry
about that]
Derrick Stolee writes:
> We've discussed in several places how to improve upon generation
> numbers. This RFC is a report based on my investigation into a
> few new options, and how they compare for Git's
On 10/31/2018 8:54 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, Oct 30 2018, Junio C Hamano wrote:
Derrick Stolee writes:
In contrast, maximum generation numbers and corrected commit
dates both performed quite well. They are frequently the top
two performing indexes, and rarely significantly
On Tue, Oct 30 2018, Junio C Hamano wrote:
> Derrick Stolee writes:
>> In contrast, maximum generation numbers and corrected commit
>> dates both performed quite well. They are frequently the top
>> two performing indexes, and rarely significantly different.
>>
>> The trade-off here now seems
On 10/29/2018 11:59 PM, Junio C Hamano wrote:
Derrick Stolee writes:
**V3: Corrected Commit Date.**
For a commit C, let its _corrected commit date_ (denoted by cdate(C))
be the maximum of the commit date of C and the commit dates of its
parents.
"maximum of the commit date of C and the
Derrick Stolee writes:
> **V3: Corrected Commit Date.**
> For a commit C, let its _corrected commit date_ (denoted by cdate(C))
> be the maximum of the commit date of C and the commit dates of its
> parents.
"maximum of the commit date of C and the corrected commit dates of
its parents"?
We've
Here is a re-formatted version of the tables I introduced earlier.
The tables were too wide for public-inbox to render correctly (when
paired with my email client). Hopefully this bulleted-list format
works better. Thanks, Stefan, for pointing out the rendering
problems!
### Test 1: `git log
On 10/29/2018 3:22 PM, Stefan Beller wrote:
Based on the performance results alone, we should remove minimum
generation numbers, (epoch, date) pairs, and FELINE index from
consideration. There are enough examples of these indexes performing
poorly.
In contrast, maximum generation numbers and
> Based on the performance results alone, we should remove minimum
> generation numbers, (epoch, date) pairs, and FELINE index from
> consideration. There are enough examples of these indexes performing
> poorly.
>
> In contrast, maximum generation numbers and corrected commit
> dates both
We've discussed in several places how to improve upon generation
numbers. This RFC is a report based on my investigation into a
few new options, and how they compare for Git's purposes on
several existing open-source repos.
You can find this report and the associated test scripts at
17 matches
Mail list logo
