quoted
"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.