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

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

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

I think the difference is that "git apply --cached foo.patch" exits
non-zero if the index isn't empty and vc-git-checkin errors when it's
not.  That ensures the commit will include only the changes in the patch
and nothing else.

I guess other VCS impls could just test if the checkout is completely
unmodified and signal an error otherwise.  That would be a bit more
restrictive but still 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?

I think the git benefit is that you can have a completely dirty checkout
(hundreds of modified files) but the command will still work fine as
long as you haven't staged other changes yet.

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

See above, I think we can at least after a "is the checkout clean?"
check.

Bye,
Tassilo