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

[Eli Zaretskii]

> Date: Mon, 29 Aug 2022 23:36:32 +0300
> Cc: larsi@gnus.org, juri@jurta.org, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> > 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).

I understand.  But how is this significant?  Doesn't "git apply"
require a valid patch as well?

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

Yes, I understand that.

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

I'm not sure why is this significant.  Doesn't committing the patch
from the index eventually update the files on disk as well?  And if
not, how is this feature useful? you get a repository where the
contents of the .git/ directory doesn't match the worktree, right?
When is this needed or useful?

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

For other changes present on disk, we cam:

  . use the equivalent of the "stash" command, where the VCS supports it
  . otherwise, commit specific files by name, where the VCS supports that
  . otherwise signal an error, asking the user to clean up the tree

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

AFAICT, Mercurial, Bazaar, RCS, CVS, and SVN all support committing an
explicit list of files, so dirty working tree shouldn't be a problem
for them.  The first two also have a "stash"-like functionality.

But even if we initially only support this in otherwise clean trees,
it will be a huge advantage vs the current situation, where this
feature is simply not available.