emacs-devel
[Top][All Lists]
Advanced

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

Re: On the adoption of transient.el


From: Dmitry Gutov
Subject: Re: On the adoption of transient.el
Date: Sun, 8 Aug 2021 04:21:22 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

Hi Juri,

On 06.08.2021 02:20, Juri Linkov wrote:

While I think Magit is a great package for discoverability etc.
I found that it's completely sufficient to use just the shell-command.
With the persistent history of the previously constructed git commands
using a flex-style completion on previous commands will even reduce
the need in some vc commands, e.g.

'M-! chm TAB' runs `git checkout master` (instead of C-x v r)
'M-! pur TAB' runs `git pull --rebase`   (instead of C-x v P)
...

Same here (except for the flex completion).

Currently I'm finishing implementation of a new vc command that
will allow committing from a diff buffer.  So for example, after
displaying all changes with e.g. 'C-x v D' you can remove
some unneeded hunks (with e.g. 'M-k' 'diff-hunk-kill'),
then on the remaining hunks type 'C-c C-c' in the diff buffer.
It will create a usual *vc-log* buffer where typing 'C-c C-c'
will commit only changes from the diff buffer.

This is a very welcome development.

Internally
it works by running three git commands:

`git stash push -m stash_name -- list_of_file_names_from_diff`
`cat diff_buffer.patch | git am` # should also handle return code

Somewhere around here, I suppose you will pop up the usual log-edit buffer?

`git stash pop -q`

For your consideration, here's a description of the strategy used by the venerable commit-patch command/package:

https://github.com/caldwell/commit-patch/blob/master/commit-patch#L212-L214

- Let the user edit a diff in the diff-mode buffer
- Save it to a file
- 'git apply --cached', to put the contents to the staging area
- 'git commit'

It might have some advantages, such as less chance of something going awry with the user's stashes due to a coding error (current, or one possibly introduced in the future).

On the flip side, I suppose it will be harder to reuse the existing 'checkin' backend function. Or generalize the exact approach to other backends, since only Git has staging area.



reply via email to

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