On 8/26/2019 2:16 PM, Elijah Newren wrote: > On Mon, Aug 26, 2019 at 6:29 AM Derrick Stolee <sto...@gmail.com> wrote: >> >> On 8/24/2019 1:40 AM, Elijah Newren wrote: >>> On Thu, Aug 22, 2019 at 6:10 AM Derrick Stolee <sto...@gmail.com> wrote: >>>> >>>> On 8/21/2019 5:52 PM, Elijah Newren wrote: >>>>> On Tue, Aug 20, 2019 at 8:12 AM Derrick Stolee via GitGitGadget >>>>> <gitgitgad...@gmail.com> 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.)
The way I built the current series is that we honor what is in the sparse-checkout as historically allowed. Always. If a user modifies the sparse-checkout to have patterns that don't match those that are added in cone mode, then Git warns the user this is the case then reverts to the old pattern-by-pattern logic. This is to have the Git client always match what another Git client would expect. (This could be JGit or an older version of Git.) A user could always disable cone mode to remove the warning and keep their sparse-checkout in its current state. Note: I have not made the "non-code-mode pattern" checks very robust. For instance, I don't check the middle characters for wildcards. This needs to happen at write time, too. The plan is to make these more robust in future versions of the series. Thanks, -Stolee
