On Wed, Jun 17, 2020 at 6:42 PM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > On 6/17/2020 7:14 PM, Elijah Newren wrote: > > Hi, > > > > Another late addition... > > > > On Thu, May 7, 2020 at 6:20 AM Derrick Stolee via GitGitGadget > > <gitgitgadget@xxxxxxxxx> wrote: > > > >> IN-TREE SPARSE-CHECKOUT DEFINITIONS > >> =================================== > >> > >> Minh's idea was simple: have sparse-checkout files in the working directory > >> and use config to point to them. As these in-tree files update, we can > >> automatically update the sparse-checkout definition accordingly. Now, the > >> only thing to do would be to ensure that the sparse-checkout files are > >> updated when someone updates the build definitions. This requires some extra > >> build validation, but would not require special tools built on every client. > > > > "In-tree" still bugs me after a few weeks; the wording seems slightly > > awkward. I don't have a good suggestion, but I'm curious if there's a > > better term. > > I am open to suggestions. It reminds me of the two hardest problems > in software engineering: > > 1. concurrency > 2. naming things > 3. off-by-one errors :-) > > But I really came here to comment on another issue I think I glossed > > over the first time around. I'm curious if all module definition > > files have to exist in the working directory, as possibly suggested > > above, or if we can allow them to just exist in the index. To give > > you a flavor for what I mean, with my sparsify tool people can do > > things like: > > ./sparsify --modules MODULE_A > > which provides MODULE_A and it's dependencies while removing all other > > directories. If MODULE_B, is not a dependency (direct or transitive) > > of MODULE_A, it will not exist in the working directory after this > > step. Our equivalent of the "in-tree" definition of MODULE_B exists > > *in* the directory for MODULE_B, because it seems to make sense for > > us. I want people to be able to do > > ./sparsify --modules MODULE_B > > and have it correctly check out all the necessary files even though > > the definition of MODULE_B wasn't even in the working directory at the > > time the command ran. (The sparsify script knows to check the working > > directory first, then fall back to the index). > > I think one tricky part of my RFC is that it _only_ looks at the > index. This allows us to read the contents even when the files are > not part of the current sparse-checkout definition. > > You mentioned in another thread that it is a bit unwieldy for a user > to rely on a committed (or staged?) file, so adding the ability to > check the working directory first is interesting. I wonder how the > timing comes into play when changing HEAD to a new commit? Seems > tricky, but solvable. Isn't that essentially the same timing issue that comes into play if you only look at the index, and are changing HEAD to a new commit?
