> So, if I could do: > > 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
Attachment:
pgpu9YGm86i3A.pgp
Description: PGP signature