Thread (4 messages) 4 messages, 2 authors, 2021-12-02

Re: 2.34 regression (and workaround): deleting untracked files both outside *and inside* desired sparsity cone

flat view

From: Elijah Newren <hidden>
Date: 2021-12-01 23:40:55

On Wed, Dec 1, 2021 at 11:19 AM Derrick Stolee [off-list ref] 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.

...
quoted
== 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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help