Re: master 4803fba487 1/2: 'C-x v v' on a diff buffer commits it as a patch (bug#52349)

[Dmitry Gutov]

On 29.08.2022 20:41, Eli Zaretskii wrote:
> > Date: Mon, 29 Aug 2022 20:05:10 +0300
> > Cc: juri@jurta.org, emacs-devel@gnu.org
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > > Given diffs in a
> > > buffer, it should be as simple as running the Patch utility via
> > > shell-command-on-region, then committing the results.  Git has a
> > > special command for that, but we don't need a special command for
> > > other VCSes, if they don't have the equivalent of "git apply".  (I'm
> > > guessing that "git apply" simply runs Patch under the hood.)
> >
> > No, 'git apply' puts the patch in a different place (index area), which
> > means our implementation doesn't need to bother with moving all existing
> > changes in the selected files somewhere else, then committing, and then
> > restoring the previously-hidden changes.
>
> I don't follow, sorry.
>
> The implementation in vc-git.el does this, AFAICT:
>
>    . creates a temporary file
>    . inserts the patch into the temporary file

Note that "the patch" will usually be a subset of the current 'git diff' 
output. But not always (the patch can be additionally modified by hand).

This feature is a replacement for the popular workflow 'git add -p; git 
commit', not for simply committing a patch, which is pretty easy to do 
already.

Though the beauty of the current approach with Git is that it supports 
either.

>    . calls "git apply --cached" on the patch in the temporary file
>    . deletes the temporary file
>
> This doesn't seem to be very different from invoking Patch on the
> diffs.  (And using shell-command-on-region avoids the need to
> explicitly create a temporary file.)

'patch < file' edits the working directory. 'git apply --cached' edits 
the index, keeping the files themselves unchanged.

> > Personally I hope we discover some popular extension to Mercurial which
> > we'll be able to use in the same way as we do Git's index area here. And
> > then say job well done and keep the less-popular and outdated backends
> > unsupported.
>
> The index thing being the problem because Git needs to have the
> changes in the index before you can commit?  Or is there any other
> reason?

Index is a solution, not the problem. The problem is other changes being 
present on disk.

> IOW, why cannot we simply patch the files, and then run the equivalent
> of vc-checkin?

I suppose we could implement a scaled-down version of this feature as a 
fallback (the one that ensures that there are no existing changes in 
affected files), but I fear the difference between the backends would 
trip up the users.

So we should start with trying to implement the "full" version first: 
for individual backends or (harder) in general.