[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 4803fba487 1/2: 'C-x v v' on a diff buffer commits it as a pa

From: Dmitry Gutov
Subject: Re: master 4803fba487 1/2: 'C-x v v' on a diff buffer commits it as a patch (bug#52349)
Date: Mon, 29 Aug 2022 23:36:32 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]