On 4/21/2021 2:56 PM, Elijah Newren wrote: > On Wed, Apr 21, 2021 at 10:27 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: >> Alternatively, we can decide to change the behavior here and send an >> error() and return failure if they try to add something that would >> live within a sparse-directory entry. I will think more on this and >> have a good answer before v2 is ready. > > See my comments on 01/10; users are already getting surprised by "git > add" today and has been going on for months (though not super > frequently). When they try to "git add" an untracked path that would > not match any path specifications in $GIT_DIR/info/sparse-checkout, > the fact that "git add" doesn't error out (or at the very least give a > warning) causes _subsequent_ commands to surprise the user with their > behavior; the fact that it is some later command that does weird stuff > (removing the file from the working tree) makes it harder for them to > try to understand and make sense of. So, I'd say we do want to change > the behavior here...and not just for sparse-indexes but > sparse-checkouts in general. > > As for how this affects the code, I think I'm behind both you and > Matheus on understanding here, but I'm starting to think it was a good > idea for me to spout my offhand comment on what looked like a funny > code smell that I thought was unrelated to your patch. Sounds like it > is causing some good digging...I'll try to read up more on the results > when you send v2. :-) I think there are enough strange thing happening with 'git add' that I want to take some time to figure out the right approach here. In v2, I will delete the changes to builtin/add.c and instead focus on making 'git status' faster with a sparse-index. The 'git add' improvements will follow in another series after I take enough time to understand all of these special modes. I think this split is especially important if we decide that changing the behavior is the best thing to do here. Thanks, -Stolee
