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

[Dmitry Gutov]

On 30.08.2022 16:01, Eli Zaretskii wrote:
> > Date: Tue, 30 Aug 2022 15:35:31 +0300
> > Cc: larsi@gnus.org, juri@jurta.org, emacs-devel@gnu.org
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > > > 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?
> >
> > It's significant in that the starting conditions is that the files are
> > already modified compared to the repository head, and the end goal is to
> > be able to pick only some of those changes for commit.
>
> Ouch!  Then this feature will be useless for me, and I'm sorry I
> wasted everyone's time based on the description in NEWS, which doesn't
> make a point of emphasizing this basic assumption.

Perhaps we could make it more useful for you as well, e.g. by applying 
all the changes from the patch first when called with 'C-u'.

I guess the problem is that the first step is not so easily automated: 
at least in my experience 'diff-apply-hunk' will either fail to find the 
files to patch (and prompt me to find them manually), or fail because of 
whitespace problems, or because it was made against some previous 
version of the code, and now has conflicts. And after I resolve all of 
this by hand, the files now have all the changes applied, and we're in 
the situation where 'C-x v D' followed by the new 'C-x v v' in diff-mode 
works just fine.

But I suppose if your patches apply cleanly most of the time, it can be 
less of a problem.

> > OTOH, the lack of support for workflow corresponding to 'git add -p' has
> > been complained about frequently, it's one of the reasons people use
> > Magit, and I felt it as well many times.
>
> I cannot agree that this feature is a reasonable solution for the
> "git add -p" workflow.  It is not interactive enough for that.

It's... a more power-user approach to the same, with a different UI. 
Experience shows that this workflow can work as an alternative, 
evidenced by the userbase of the commit-patch package.

diff-mode provides commands to delete hunks, split them, and even allows 
one to edit individual characters (something that 'git add -p' doesn't 
provide). So I'd argue this way might even be more powerful.