On 17 February 2017 at 10:26, Jeff King wrote:
> On Sat, Feb 04, 2017 at 02:43:01PM +0100, Jakub Narębski wrote:
>
>> Do Git use EWAH / EWOK bitmaps for reachability analysis, or is it still
>> limited to object counting?
>> >>>
>> >>> At GitHub we are using them for --contains analysis,
On Sat, Feb 04, 2017 at 02:43:01PM +0100, Jakub Narębski wrote:
> Do Git use EWAH / EWOK bitmaps for reachability analysis, or is it still
> limited to object counting?
> >>>
> >>> At GitHub we are using them for --contains analysis, along with mass
> >>> ahead/behind (e.g., as in https:
On 20 July 2016 at 15:02, Jeff King wrote:
> On Wed, Jul 20, 2016 at 02:07:38AM +0200, Jakub Narębski wrote:
>> W dniu 2016-06-30 o 00:00, Jeff King pisze:
>>> On Wed, Jun 29, 2016 at 11:49:35PM +0200, Jakub Narębski wrote:
>>
Do Git use EWAH / EWOK bitmaps for reachability analysis, or is it
On Wed, Jul 20, 2016 at 02:07:38AM +0200, Jakub Narębski wrote:
> W dniu 2016-06-30 o 00:00, Jeff King pisze:
> > On Wed, Jun 29, 2016 at 11:49:35PM +0200, Jakub Narębski wrote:
>
> >> Do Git use EWAH / EWOK bitmaps for reachability analysis, or is it still
> >> limited to object counting?
> >
>
W dniu 2016-06-30 o 00:00, Jeff King pisze:
> On Wed, Jun 29, 2016 at 11:49:35PM +0200, Jakub Narębski wrote:
>> Do Git use EWAH / EWOK bitmaps for reachability analysis, or is it still
>> limited to object counting?
>
> At GitHub we are using them for --contains analysis, along with mass
> ahead/
W dniu 2016-07-05 o 13:43, Johannes Schindelin pisze:
> On Wed, 29 Jun 2016, Jeff King wrote:
>
>> I haven't thought hard specifically about merge bases computation, so
>> perhaps that is a case that isn't helped at all.
>
> I guess it is not helped by generation numbers.
>
> But then, we often
Hi Peff,
On Wed, 29 Jun 2016, Jeff King wrote:
> I haven't thought hard specifically about merge bases computation, so
> perhaps that is a case that isn't helped at all.
I guess it is not helped by generation numbers.
But then, we often ask: "is commit A an ancestor of commit B" e.g. to
check w
Jeff King writes:
> So I think it would be more productive to put a check like this in "git
> commit" rather than (or perhaps in addition to) fsck. That prevents
> us creating the broken relationship, but it does still mean the user may
> have to to go back and tell the original committer that th
W dniu 2016-07-01 o 08:54, Jeff King pisze:
> On Thu, Jun 30, 2016 at 12:30:31PM +0200, Jakub Narębski wrote:
>
>>> This is one of the open questions. My older patches turned them off when
>>> replacements and grafts are in effect.
>>
>> Well, if you store the cache of generation numbers in the pa
W dniu 2016-07-01 o 05:17, Jeff King pisze:
> On Thu, Jun 30, 2016 at 11:12:52AM -0700, Linus Torvalds wrote:
>
>> I do think that it's ok to cache generation numbers somewhere if there
>> is an algorithm that can make use of them, but every time this comes
>> up, it's just not been important enou
On Thu, Jun 30, 2016 at 12:30:31PM +0200, Jakub Narębski wrote:
> > This is one of the open questions. My older patches turned them off when
> > replacements and grafts are in effect.
>
> Well, if you store the cache of generation numbers in the packfile, or in
> the index of the packfile, or in
On 01.07.2016 05:17, Jeff King wrote:
On Thu, Jun 30, 2016 at 11:12:52AM -0700, Linus Torvalds wrote:
I do think that it's ok to cache generation numbers somewhere if there
is an algorithm that can make use of them, but every time this comes
up, it's just not been important enough to make a big
On Thu, Jun 30, 2016 at 11:12:52AM -0700, Linus Torvalds wrote:
> I do think that it's ok to cache generation numbers somewhere if there
> is an algorithm that can make use of them, but every time this comes
> up, it's just not been important enough to make a big deal and a new
> incompatible obje
On Thu, Jun 30, 2016 at 11:12:52AM -0700, Linus Torvalds wrote:
> On Thu, Jun 30, 2016 at 3:30 AM, Jakub Narębski wrote:
> >
> > P.S. Having Git ensure that committerdate (as an epoch) is greater
> > than committerdates of its parents at the commit creation time (with
> > providing warning about t
W dniu 2016-06-30 o 20:12, Linus Torvalds pisze:
> On Thu, Jun 30, 2016 at 3:30 AM, Jakub Narębski wrote:
>>
>> P.S. Having Git ensure that committerdate (as an epoch) is greater
>> than committerdates of its parents at the commit creation time (with
>> providing warning about time skew, perhaps n
On Thu, Jun 30, 2016 at 3:30 AM, Jakub Narębski wrote:
>
> P.S. Having Git ensure that committerdate (as an epoch) is greater
> than committerdates of its parents at the commit creation time (with
> providing warning about time skew, perhaps not doing it if skew is
> too large) would be not costly
W dniu 2016-06-30 o 00:00, Jeff King pisze:
> On Wed, Jun 29, 2016 at 11:49:35PM +0200, Jakub Narębski wrote:
>
>>> So this is the ideal case for generation numbers (the worst cases are
>>> when the things you are looking for are in branchy, close history where
>>> the generation numbers don't tel
On Wed, Jun 29, 2016 at 03:11:39PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yes, though generation numbers can help with more questions (e.g., "what
> > is the merge base").
>
> Hmm, how? I have two commits, with generation number 38 and 47,
> respectively. What generation numbe
On 29.06.2016 22:39, Junio C Hamano wrote:
Stefan Beller writes:
On Wed, Jun 29, 2016 at 11:59 AM, Junio C Hamano wrote:
On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz
wrote:
This is no RFE but rather recurring thoughts whenever I'm working with
commit graphs: a topological index attribut
Jeff King writes:
> Yes, though generation numbers can help with more questions (e.g., "what
> is the merge base").
Hmm, how? I have two commits, with generation number 38 and 47,
respectively. What generation number does the commit that is the
merge base of these two commits?
I know we can s
On Wed, Jun 29, 2016 at 11:49:35PM +0200, Jakub Narębski wrote:
> > So this is the ideal case for generation numbers (the worst cases are
> > when the things you are looking for are in branchy, close history where
> > the generation numbers don't tell you much; but in such cases the
> > walking is
W dniu 2016-06-29 o 22:56, Jeff King pisze:
> On Wed, Jun 29, 2016 at 01:39:17PM -0700, Junio C Hamano wrote:
>
>>> Would it make sense to refuse creating commits that have a commit date
>>> prior to its parents commit date (except when the user gives a
>>> `--dammit-I-know-I-break-a-wildy-used-he
On Wed, Jun 29, 2016 at 02:37:17PM -0700, Stefan Beller wrote:
> On Wed, Jun 29, 2016 at 1:54 PM, Stefan Beller wrote:
> > Chances are that the 10 years of history may be correct time wise as long
> > as people don't introduce a bad date malevolently.
> >
>
> To answer my own speculation:
> Even
On Wed, Jun 29, 2016 at 1:54 PM, Stefan Beller wrote:
> Chances are that the 10 years of history may be correct time wise as long
> as people don't introduce a bad date malevolently.
>
To answer my own speculation:
Even git.git violates the timing property, so there is no hope to find
many projec
On Wed, Jun 29, 2016 at 1:39 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Wed, Jun 29, 2016 at 11:59 AM, Junio C Hamano wrote:
>>> On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz
>>> wrote:
This is no RFE but rather recurring thoughts whenever I'm working with
commit grap
W dniu 2016-06-29 o 20:59, Junio C Hamano pisze:
> On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz
> wrote:
>
>> This is no RFE but rather recurring thoughts whenever I'm working with
>> commit graphs: a topological index attribute for commit objects would be
>> incredible useful. By "topological
On Wed, Jun 29, 2016 at 01:39:17PM -0700, Junio C Hamano wrote:
> > Would it make sense to refuse creating commits that have a commit date
> > prior to its parents commit date (except when the user gives a
> > `--dammit-I-know-I-break-a-wildy-used-heuristic`)?
>
> I think that has also been discu
Stefan Beller writes:
> On Wed, Jun 29, 2016 at 11:59 AM, Junio C Hamano wrote:
>> On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz
>> wrote:
>>> This is no RFE but rather recurring thoughts whenever I'm working with
>>> commit graphs: a topological index attribute for commit objects would be
>>
On Wed, Jun 29, 2016 at 11:59 AM, Junio C Hamano wrote:
> On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz
> wrote:
>> This is no RFE but rather recurring thoughts whenever I'm working with
>> commit graphs: a topological index attribute for commit objects would be
>> incredible useful. By "topolo
On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz
wrote:
> This is no RFE but rather recurring thoughts whenever I'm working with
> commit graphs: a topological index attribute for commit objects would be
> incredible useful. By "topological index" I mean a simple integer for which
> following condi
This is no RFE but rather recurring thoughts whenever I'm working with
commit graphs: a topological index attribute for commit objects would be
incredible useful. By "topological index" I mean a simple integer for
which following condition holds true:
if commit C is part of the history of comm
31 matches
Mail list logo
