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

[Dmitry Gutov]

On 08.12.2021 21:57, Juri Linkov wrote:
> > > 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’.

Then it will probably be fine, most of the time?

> 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).

Yes, the commit-patch (external package) workflow. It totally sounds 
fine to me, though it might require some additional explanation when a 
random user tries to take advantage of it (Git's interactive command UI 
is more self-explanatory).

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

Couldn't you 'git apply external/patch/file/name.ext' first?

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

I don't have a particularly strong opinion, but the approach with 'git 
apply --cached' followed by 'git commit' seems easier to implement and 
avoids changing the file contents on disk, or risking any of the 
stashes. So I'd try implementing it first and then see if the remaining 
problems are worth the trouble of doing it in a more difficult way.