bug#52349: 29.0.50; vc-git and diff-mode: stage hunks

[Juri Linkov]

>> The problem is that 'git apply --cached' doesn't perform the merge
>> with other changes in the same file, whereas 'git stash pop'
>> merges committed changes with uncommitted changes.
>
> This seems to address our previous discussion, rather than the difference
> vs. diff-hl.
>
> Anyway, I don't know if it is a problem.
>
> E.g., you might want to edit a diff (if you know how, which is
> a significant "if") to commit a slightly different change than what the
> current file contents show.

Actually, not quite edit, but only to delete unneeded hunks with ‘k’.

The intention is to emulate the interactive command `git add --patch`
that has many keys:

  y - stage this hunk
  n - do not stage this hunk
  q - quit; do not stage this hunk or any of the remaining ones
  a - stage this hunk and all later hunks in the file
  d - do not stage this hunk or any of the later hunks in the file
  g - select a hunk to go to
  / - search for a hunk matching the given regex
  j - leave this hunk undecided, see next undecided hunk
  J - leave this hunk undecided, see next hunk
  k - leave this hunk undecided, see previous undecided hunk
  K - leave this hunk undecided, see previous hunk
  s - split the current hunk into smaller hunks
  e - manually edit the current hunk
  ? - print help

Instead of these numerous keys, in Emacs it should be sufficient
just to type ‘k’ (diff-hunk-kill) a few times on the output of ‘C-x v D’
in the *vc-diff* buffer (and maybe some splitting).

> But then, I'm not sure you'll want the applied change to be reflected in
> the file on disk too (as opposed to being saved in the commit). I probably
> won't (and it would let us avoid the awkward step of seeing the stashing
> operation temporarily reflected in the file contents, as well as any
> possible conflicts).
>
> Either way, the editing of the diff that's more complex than splitting
> hunks and deleting some of them will probably be very rare. So the behavior
> in this scenario doesn't have to affect our choice of implementation.

I had in mind a different scenario: when you have uncommitted changes
in one part of the file, and receive an external patch from outside of the repo
with changes in another part of the file, and need to commit it.
But I admit such scenario is very rare.

So if using ‘git apply --cached’ is the preferred solution,
then I could finish the patch with it.