bug#38343: 27.0.50; vc git: Cannot edit outgoing log (like git commit --amend)

[Fredrik Nyqvist <fredrik.nyqvist94@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]

Den ons 27 nov. 2019 kl 01:10 skrev Dmitry Gutov <dgutov@yandex.ru>:

> On 26.11.2019 22:43, Fredrik Nyqvist wrote:
> > Den mån 25 nov. 2019 kl 23:49 skrev Dmitry Gutov <dgutov@yandex.ru
> > <mailto:dgutov@yandex.ru>>:
> >
> >     On 25.11.2019 22:16, Fredrik Nyqvist wrote:
> >      > Yes, I have tried the option you mention to edit the last commit
> >     with
> >      > C-x C-e and it is working fine.
> >      > But It seems that it only allows amending the last commit if I
> have
> >      > edited a file.
> >
> >     Yes. Not sure how to change an arbitrary commit in Git anyway
> (without
> >     interactive rebase). The best approximation looks like this:
> >
> >     https://stackoverflow.com/a/48999882/615245
> >
> >
> > I am not sure how to do it in a good way either. Maybe the option to
> > edit an
> > older commit message could be skipped for vc-git. And then just allow
> amend
> > on the latest one.
>
> The question is how to skip. Error in the end, after the user has
> already written the new commit message?
>
> Or add a backend predicate action, like "can edit revision ##". That's
> one more action, though.
>

If the user is trying to edit an older commit message from the log-buffer
(with log-view-modify-change-comment) I think an error message is good,
before writing the commit message ("can't edit revision ##"). I feel that
it will be more clear at least.

Also we should think about how to handle a commit that has already been
pushed. In this case I guess a force push is needed, but maybe that is not
good to hide. Maybe it is better to just allow edit on local commits then.

[-- Attachment #2: Type: text/html, Size: 2390 bytes --]