> 	So, if I could do:
quoted text
>
> 	git apply --index
> 	git commit-index-content <files that add the test case>
> 	git commit-index-content
>
> 	Then this would do exactly what I want. I wouldn't even have
> 	to think about whether my local modifications are to any of
> 	the same paths as touched by the patch.

BTW, the current "apply --index" doesn't allow what I imagined in the
scenario above. It notices that the affected file is different in the
working tree compared to the index and just refuses to do anything.

Given that safety-valve in git-apply, the current behavior of "git
commit paths" would allow for splitting a submitted patch into two
commits.

The difference is that it only works if the local modifications do not
affect any of the same paths as the patch. The user is freed from
worrying about this somewhat, since if it's not the case, then
git-apply just complains and doesn't do anything.

But what might be very interesting is a modified "git-apply --index"
that would not fail in this case, but would instead do the following:

	1. Apply the patch to the working tree

	2. Apply the patch to the index

And of course, if either fails then the entire apply operation fails,
leaving no changes to working tree or to the index.

With that new git-apply behavior, then the scenario I outlined above
would work, and would work in spite of any changes to the same file in
both the working tree and the index. It would also require the
separate commands for commit-index-content vs.
commit-working-tree-content as described in my original message above.

-Carl