Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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? > > >

Re: topological index field for commit objects

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 >

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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 > >

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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)

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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?

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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 >>>

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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:

Re: topological index field for commit objects

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 >>

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

Re: topological index field for commit objects

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

topological index field for commit objects

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