Re: [PATCH 2/7] sparse-checkout: correctly set non-cone mode when expected
- From
Elijah Newren <newren@gmail.com>
- Date
- Feb 15, 2022, 03:18 UTC
- Message-ID
- <CABPp-BHJ52Eqm3Zwf2Hy2pgbf1mvVEPPdmqGDvzoQbS9SeTsMA@mail.gmail.com>
- In-Reply-To
- <40a88efa-a07f-417b-a5c5-0a6e651cfa8c@github.com>
On Mon, Feb 14, 2022 at 7:44 AM Derrick Stolee <derrickstolee@github.com> wrote:
Show 9 quoted lines
>
> On 2/12/2022 7:39 PM, Elijah Newren via GitGitGadget wrote:
> > From: Elijah Newren <newren@gmail.com>
> >
> > commit f2e3a218e8 ("sparse-checkout: enable `set` to initialize
> > sparse-checkout mode", 2021-12-14) made the `set` command able to
> > intialize sparse-checkout mode, but it also had to function when
>
> s/intialize/initialize/Thanks.
Show 12 quoted lines
> > sparse-checkout mode was already setup and the user just wanted to > > change the sparsity paths. So, if the user passed --cone or --no-cone, > > then we should override the current setting, but if they didn't pass > > either, we should use whatever the current cone mode setting is. > > > > Unfortunately, there was a small error in the logic in that it would not > > set the in-memory cone mode value (core_sparse_checkout_one) when > > --no-cone was specified, but since it did set the config setting on > > disk, any subsequent git invocation would correctly get non-cone mode. > > As such, the error did not previously matter. However, a sbusequent > > s/sbusequent/subsequent/
Likewise.
Show 21 quoted lines
> > commit will add some logic that depends on core_sparse_checkout_cone
> > being set to the correct mode, so make sure it is set consistently with
> > the config values we will be writing to disk.
> >
> > Signed-off-by: Elijah Newren <newren@gmail.com>
> > ---
> > builtin/sparse-checkout.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/builtin/sparse-checkout.c b/builtin/sparse-checkout.c
> > index 510cb89b544..8d595189ea3 100644
> > --- a/builtin/sparse-checkout.c
> > +++ b/builtin/sparse-checkout.c
> > @@ -399,6 +399,8 @@ static int update_modes(int *cone_mode, int *sparse_index)
> > core_sparse_checkout_cone = 1;
> > } else {
> > mode = MODE_ALL_PATTERNS;
> > + if (record_mode)
> > + core_sparse_checkout_cone = 0;
>
> Is there a special reason why this is guarded by "if (record_mode)"?It turns out it's not needed.
I was worried about changing core_sparse_checkout_cone when we got to this function without either --cone or --no-cone mode being specified, but re-checking the code, in such a case *cone_mode would have been set to core_sparse_checkout_cone a few lines above, so setting core_sparse_checkout_cone unconditionally here is safe. I will remove the check.