All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Keller, Jacob E" <jacob.e.keller@intel.com>
To: Derrick Stolee <derrickstolee@github.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Cc: Junio C Hamano <gitster@pobox.com>,
	Jacob Keller <jacob.keller@gmail.com>
Subject: RE: [PATCH] name-rev: use generation numbers if available
Date: Mon, 28 Feb 2022 20:59:16 +0000	[thread overview]
Message-ID: <CO1PR11MB508965B6F5F4A4B8D45649BFD6019@CO1PR11MB5089.namprd11.prod.outlook.com> (raw)
In-Reply-To: <117ed093-f3e0-ba24-2364-74e43a1306fe@github.com>



> -----Original Message-----
> From: Derrick Stolee <derrickstolee@github.com>
> Sent: Monday, February 28, 2022 12:24 PM
> To: Keller, Jacob E <jacob.e.keller@intel.com>; git@vger.kernel.org
> Cc: Junio C Hamano <gitster@pobox.com>; Jacob Keller
> <jacob.keller@gmail.com>
> Subject: Re: [PATCH] name-rev: use generation numbers if available
> 
> On 2/28/2022 3:20 PM, Keller, Jacob E wrote:
> > On 2/28/2022 11:50 AM, Derrick Stolee wrote:
> >> On 2/28/2022 2:07 PM, Jacob Keller wrote:
> >>> From: Jacob Keller <jacob.keller@gmail.com>
> >>> +/* Check if a commit is before the cutoff. Prioritize generation numbers
> >>> + * first, but use the commit timestamp if we lack generation data.
> >>> + */
> >>> +static int commit_is_before_cutoff(struct commit *commit)
> >>> +{
> >>> +	if (generation_cutoff < GENERATION_NUMBER_INFINITY)
> >>> +		return commit_graph_generation(commit) < generation_cutoff;
> >>> +
> >>> +	return commit->date < cutoff;
> >>> +}
> >>
> >> There are two subtle things going on here when generation_cutoff is
> >> zero:
> >>
> >> 1. In a commit-graph with topological levels _or_ generation numbers v2,
> >>    commit_graph_generation(commit) will always be positive, so we don't
> >>    need to do the lookup.
> >
> > I.e. once we have a generation_cutoff of 0 we can just completely bypass
> > the lookup, saving some time.
> >
> > I think we can do "return generation_cutoff &&
> > commit_graph_generation(commit) < generation_cutoff"
> >
> >>
> >> 2. If the commit-graph was written by an older Git version before
> >>    topological levels were implemented, then the generation of commits
> >>    in the commit-graph are all zero(!). This means that the logic here
> >>    would be incorrect for the "all" case.
> >>
> >> The fix for both cases is to return 1 if generation_cutoff is zero:
> >>
> >
> > I think you mean return 0? Because this returns true if the commit is
> > before the cutoff, but false if its not. (i.e. if its true, we should
> > stop searching this commit, but if its false we should continue searching?
> 
> Yes, sorry I had it mixed up. Your generation_cutoff && ... approach
> will work in that case.
> 

Alright. Will fix that for v2.

> >>> +test_expect_success 'name-rev --all works with non-monotonic' '
> >>
> >> This is working because of the commit-graph, right? We still have
> >> it from the previous test, so we aren't testing that this works
> >> when we only have the commit date as a cutoff.
> >>
> >
> > I can either extend this test or add a separate test which covers this.
> > The test failed before I added the commit graph line.
> >
> >>> +	(
> >>> +		cd non-monotonic &&
> >>> +
> >>> +		cat >expect <<-\EOF &&
> >>> +		E
> >>> +		D
> >>> +		D~1
> >>> +		D~2
> >>> +		A
> >>> +		EOF
> >>> +
> >>> +		git log --pretty=%H >revs &&
> >>> +		git name-rev --tags --annotate-stdin --name-only <revs >actual
> &&
> >>> +
> >>> +		test_cmp expect actual
> >>> +	)
> >>
> >> Do you want to include a test showing the "expected" behavior
> >> when there isn't a commit-graph file? You might need to delete
> >> an existing commit-graph (it will exist in the case of
> >> GIT_TEST_COMMIT_GRAPH=1).
> >>
> >
> > This test actually is intended to show that it works regardless of
> > whether we have a commit graph. (Because in --annotate-stdin mode we
> > disable the heuristic since we don't know what commits we'll see in advance)
> >
> > Is there a good way to delete the graph file?
> 
> The basic way is "rm -rf .git/info/commit-graph*" to be absolutely
> sure (there might be an incremental commit-graph which appears as
> a "commit-graphs" directory).
> 
> >> I also see that you intended to test the "--all" option, which
> >> is not included in your test. That's probably the real key to
> >> getting this test to work correctly. Deleting the graph will
> >> probably cause a failure on this test unless "--all" is added.
> >>
> >
> > Actually both --all and --annotate-stdin disable the heuristic. However,
> > I think adding a test for both makes sense.
> 
> Ah. OK. They could be assertions within the same test since the
> output is expected to be the same.
> 
> Thanks,
> -Stolee

  reply	other threads:[~2022-02-28 20:59 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28 19:07 [PATCH] name-rev: use generation numbers if available Jacob Keller
2022-02-28 19:50 ` Derrick Stolee
2022-02-28 20:20   ` Keller, Jacob E
2022-02-28 20:24     ` Derrick Stolee
2022-02-28 20:59       ` Keller, Jacob E [this message]
2022-02-28 21:50 [PATCH v2 0/1] " Jacob Keller
2022-02-28 21:50 ` [PATCH] " Jacob Keller
2022-03-01  2:36   ` Junio C Hamano
2022-03-01  7:08     ` Jacob Keller
2022-03-01  7:09       ` Jacob Keller
2022-03-01  7:33       ` Junio C Hamano
2022-03-01 15:09         ` Derrick Stolee
2022-03-01 19:52           ` Keller, Jacob E
2022-03-01 19:56             ` Derrick Stolee
2022-03-01 20:22               ` Junio C Hamano
2022-03-01 22:46                 ` Keller, Jacob E
2022-03-03  1:10                   ` Junio C Hamano
2022-03-07 20:22                     ` Jacob Keller
2022-03-07 20:26                       ` Derrick Stolee
2022-03-07 22:30                         ` Keller, Jacob E
2022-03-07 22:43                           ` Derrick Stolee
2022-03-07 22:52                           ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CO1PR11MB508965B6F5F4A4B8D45649BFD6019@CO1PR11MB5089.namprd11.prod.outlook.com \
    --to=jacob.e.keller@intel.com \
    --cc=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jacob.keller@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.