>> "am" is about recording what is in the patch as a commit. > > Does that mean it should behave like "apply --index"? Or more like > cherry-pick? It should behave like a manual edit (after widening the area of interest by adjusting sparsity specification, if needed) followed by "git add" followed by "git commit". > The command > $ edit path/outside/sparse/specification > doesn't make sense to me; the file (and perhaps also its leading > directories) are missing. Most editors will probably tell you that > you are editing a new file, but then it's more of a "rewrite from > scratch" than an "edit". If it is a new file, read it with "mkdir -p $(dirname $that_file)" prefixed. If it is an existing file, then "checkout $that_file" instead. And then adjust your sparsity specification so that the path is now within your area of interest. > Typically, we'd expect users who want to edit such files to do so by > first running the `add` or `set` subcommands of sparse-checkout to > change their sparse specification so that the file becomes present. > But then it's no longer outside the sparse specification. So, I'm not > sure how this angle could help guide our direction. The fact that you accept and attempt to apply and make it into a commit already indicates your intention that the paths touched by the patch are now in your area of interest, just like whichever paths you decide to manually edit and record the changes you made, so it would be the most user friendly to automatically adjust the sparsity specification to allow them do exactly that, I would think. That is how I look at the "am" command, anyway.
