Re: 2.34 regression (and workaround): deleting untracked files both outside *and inside* desired sparsity cone
- From
Elijah Newren <newren@gmail.com>
- Date
- Dec 1, 2021, 23:40 UTC
- Message-ID
- <CABPp-BHSPQMUw8a6E7Kz+7L6NuD8c9GrHdTMf_rBzQR+2VGs-Q@mail.gmail.com>
- In-Reply-To
- <9c7afd37-9940-e6e7-da41-8a44840defb3@gmail.com>
On Wed, Dec 1, 2021 at 11:19 AM Derrick Stolee <stolee@gmail.com> wrote:
>
...
> We use the sparse-checkout builtin. From the Scalar patch series, > you can see that we don't call "git clone" at all, but instead > "scalar clone" does a lot with "git init" and works from there by > setting config and fetching at the correct time.
Ah, thanks for the correction. I had seen that, but forgotten.
...
Show 22 quoted lines
> > == Long term proposal == > > > > Make `set` do both the work of `init` and `set`. > > > > This means: > > * `set` gains the ability to parse both --cone and --sparse-index > > (in addition to --stdin, etc.) > > * If the sparse-index is not initialized, `set` does the > > initialization work of `init`. > > * Modify the `init` documentation to mark it as deprecated, > > mentioning the 2-3 bugs above as reasons why. > > * We could effectively just turn `git sparse-checkout init ...` into > > an alias for `git sparse-checkout set ...`, since init's parameters > > would be a subset of those that `set` accepts. However, the latter > > might interact badly with allowing a user to toggle sparse-index on > > and off in the middle of a sparse-checkout...so maybe we need > > something more? Alternatively, we could leave `init` as-is and just > > consider it set in concrete, possibly risking it becoming > > non-functional in a future upgrade. Hmm... > > I think this is a good plan. Making 'init' the same as 'set' with > no paths makes sense to me.
Cool, I'll get to work on it.
> We would want to be careful now that > "--option" could be interpreted as a path to recommend using > > git sparse-checkout set <options> -- <path1> ... <pathN>
Makes sense. However, wasn't this already an issue when you added `--stdin` as an option for the `set` command?
> While you are here, I would be interested in making 'git clone > --sparse' default to cone mode. Or, should it be 'git clone > --sparse=cone' or something? Not making it default to cone mode > is a big regret of mine.
I agree it'd be much nicer to have it default to cone mode, and the big warning in git-sparse-checkout.txt might permit us to do so. A few related questions:
* Should we document how to change from cone mode to non-cone mode? We have --sparse-index, --no-sparse-index, and --cone flags, but no --no-cone one. Should we? (Do these flags belong somewhere other than `init` since it's toggling some other flag while already using a sparse-checkout?)
* Should we clean up the wording in clone's --sparse option? In particular:
--sparse:: Initialize the sparse-checkout file so the working directory starts with only the files in the root of the repository. The sparse-checkout file can be modified to grow the working directory as needed.
This wording seems to suggest direct editing of .git/info/sparse-checkout, and might confuse users. Perhaps the last sentence could change "sparse-checkout file can be modified" -> "sparse-checkout command can be used" or something like that?