On Mon, Aug 26, 2019 at 6:29 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > On 8/24/2019 1:40 AM, Elijah Newren wrote: > > On Thu, Aug 22, 2019 at 6:10 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > >> > >> On 8/21/2019 5:52 PM, Elijah Newren wrote: > >>> On Tue, Aug 20, 2019 at 8:12 AM Derrick Stolee via GitGitGadget > >>> <gitgitgadget@xxxxxxxxx> wrote: > > > >> In this series, I turn `core.sparseCheckout` into a tri-state, and only > >> try to validate the sparse-checkout when `core.sparseCheckout=cone`. > >> This avoids spending time on the validation when someone is content using > >> the existing feature. > >> > >> The _intent_ of using the sparse-checkout file and no extra data structure > >> was to let other clients (or an older client) read the sparse-checkout data > >> and result in the same working directory. One thing I realized after > >> submitting is that the tri-state config variable will cause old clients > >> to error on parsing the non-boolean value. Instead, in v2 I will introduce > >> a new boolean config variable "core.sparseCheckoutCone" that will do the > >> same thing as the current series when `core.sparseCheckout=cone` and will > >> fix this compat scenario. > > > > Once we are forced to use yet another config variable, we may as well > > use yet another config file ($GITDIR/info/sparse-checkout-cone or > > something; or maybe a less specific name with greater future > > compatibility via some version marking in it). > > I'm hesitant to include a second "source of truth," as that can cause > issues when users modify the sparse-checkout file directly. Since the > existing way to interact with the sparse-checkout is to directly edit > the file, I want to be as careful as possible around users who modify > that themselves. The caveat is that if they specify "cone" mode then > they will get warnings and worse performance if they modify it outside > the limited patterns we allow. Wait...does that mean you allow mixing and matching both regular style sparse-checkout declarations with cone-mode style declarations within the same file? Are the non-cone mode entries ignored? Does it fallback to non-cone mode for all entries? Or does that mean you allow checking out both old and new styles of filesets, where you optimize the cone-mode style declarations with your hashsets, and have the remaining ones fall back to the old O(N*M) matching? (I think it does the last of those, right?) If you support both, it sounds like you naturally support doing cone mode with allowing people to also grab a handful of additional files without the rest of their directories or parents. It's just that folks who want to do that will ask for a way to turn off any warnings you spew, and if you turn the warnings off, then people who meant to get cone behavior but mistyped stuff might complain about no warnings. Hmm.... (Just trying to think things through out loud; I don't necessarily know what's good or bad here, just voicing what I think might happen.)
