Re: On the adoption of transient.el

[Dmitry Gutov <dgutov@yandex.ru>]

On 11.08.2021 09:58, Juri Linkov wrote:
>> Sorry, I don't understand. Could you explain the scenario in more detail?
> This is the shortest test case:
> 
> 1. make changes in one part of a file
> 2. create a patch with changes in another part of the same file
> 3. git apply --cached a.patch
> 4. git commit -m "Apply a.patch"
> 5. git commit -a -m "Commit original file changes"
> 
> The last commit reverts the changes committed from the patch.

I see, thanks.

To respond to that, I think even among those who would use this feature 
(advanced users), most aren't going to edit the diff outputted by 'C-x v 
D' aside from splitting and deleting hunks (available by bindings 'C-c 
C-s' and 'k'). And those kind of changes shouldn't trigger this problem.

Second, if someone does edit the patch further (after switching off the 
read-only-mode in the diff buffer), they might actually expect this 
behavior: like, I edited the changes for commit, but I didn't edit the 
file itself; should the working copy of the file really incorporate 
those changes? And if they're using something like diff-hl-mode, they 
would notice the effect quickly (whether they expected it or not), and 
could undo/apply that missing change easily.

There is a similar solution to stashes using 'git apply', but it seems 
finicky. Assuming a.patch changes file.ext:

6. git add file.ext
7. git apply --3way a.patch

And see the conflict markers (if the changes do indeed conflict, which 
is not necessarily the case).

I'm not sure triggering conflicts on commit is the best idea, but the 
"no conflict" situation seems nice.

Either way, it requires a user with advanced skill. A simpler 
implementation that would require them to do an extra step manually in 
unusual scenarios doesn't seem too bad.