All of lore.kernel.org
 help / color / mirror / Atom feed
From: Derrick Stolee <derrickstolee@github.com>
To: Jacob Keller <jacob.keller@gmail.com>,
	Junio C Hamano <gitster@pobox.com>
Cc: "Keller, Jacob E" <jacob.e.keller@intel.com>,
	Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH] name-rev: use generation numbers if available
Date: Mon, 7 Mar 2022 15:26:32 -0500	[thread overview]
Message-ID: <39f08f98-be0f-bba7-c41a-1c9eb6182a67@github.com> (raw)
In-Reply-To: <CA+P7+xo=UwUQ422o36_8XGNWoYjROGi5wBT4=jy4ThJBs_z=Xw@mail.gmail.com>

On 3/7/2022 3:22 PM, Jacob Keller wrote:
> On Wed, Mar 2, 2022 at 5:10 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> "Keller, Jacob E" <jacob.e.keller@intel.com> writes:
>>
>>> Let's clarify. There are two versions of the test in this version:
>>>
>>> 1) test which enables commit graph and tests that it does the right behavior.
>>>
>>> 2) test which removes commit graph and tests that it behaves the old way.
>>>
>>>
>>> test (1) checks the flow with the commit graph enabled, and verifies that with a commit graph the new behavior is used. This test will fail if you revert the name-rev commit-graph support.
>>>
>>> test (2) always performs the way we don't like. (since we disable the commit graph and the new flow doesn't kick in) This is the test I think I will eliminate in the next revision.
>>>
>>>
>>> I will remove the 2nd test, since the first test covers the change
>>> in behavior just fine, and I think I agree we don't need to set
>>> in-stone the implementation without commit graph.
>>>
>>> I will also look at adding a test which performs a count of which
>>> revisions get inspected and makes sure that we actually are doing
>>> the optimization.
>>
>> Sounds like a sensible thing to do.
>>
>> In any case, in the current patch, #2 is not working in
>> linux-TEST-vars job at CI.  You can visit this URL
>>
>> https://github.com/git/git/runs/5400048732?check_suite_focus=true#step:4:68062
>>
>> while logged into your GitHub account for details.
> 
> Looks like this job sets all the TEST variables including
> GIT_TEST_COMMIT_GRAPH=1? The negative test passes because the commit
> graph is enforced on and we then succeed even though we were trying to
> test the negative case.
> 
> I'm going to remove that test in v3 anyways, so I don't think it is a
> big deal. However, I wonder is there some way to mark a test as
> explicitely "don't run if GIT_TEST_COMMIT_GRAPH is set"?

Typically, we try to keep them compatible in both cases. However,
you can set GIT_TEST_COMMIT_GRAPH=0 for the test, if you want. Be
careful to only change it locally to the single test, not "globally"
to the full test script.

Thanks,
-Stolee

  reply	other threads:[~2022-03-07 20:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28 21:50 [PATCH v2 0/1] name-rev: use generation numbers if available Jacob Keller
2022-02-28 21:50 ` [PATCH v2 1/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 [this message]
2022-03-07 22:30                         ` Keller, Jacob E
2022-03-07 22:43                           ` Derrick Stolee
2022-03-07 22:52                           ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2022-02-28 19:07 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

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=39f08f98-be0f-bba7-c41a-1c9eb6182a67@github.com \
    --to=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jacob.e.keller@intel.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.