Jerry Zhang <jerry@xxxxxxxxxx> writes: > I can see what you mean about the user safety issue. However, > my specific use case (see cover letter) involves an index that does not > match HEAD, and wouldn't be possible at all if we forced the index to > match HEAD. Furthermore git-apply --cached even without --3way > doesn't force the index to match HEAD either, so why force it now? Primarily because we tend to be extra careful before mergy operation than any other operation. Especially without --3way, apply (with or without --cached/--index) is extra careful to make itself all-or-none operation to be safe, so that there is no mixed mess that requires manual intervention (which would further increase the risk of mistakes). It is OK to introduce a new option to allow a dirty index, and your tool can pass that option when it calls "apply --cached --3way", but it would be safe to require a clean index (it does not matter how dirty the working tree is ;-) by default.
