bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Fredrik Nyqvist
Subject: bug#38343: 27.0.50; vc git: Cannot edit outgoing log (like git commit --amend)
Date: Thu, 28 Nov 2019 21:48:57 +0100


Den ons 27 nov. 2019 kl 23:08 skrev Dmitry Gutov <dgutov@yandex.ru>:
On 27.11.2019 22:11, Fredrik Nyqvist wrote:
>
>
> Den ons 27 nov. 2019 kl 01:10 skrev Dmitry Gutov <dgutov@yandex.ru
> <mailto: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>
>      > <mailto: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.

Then it seems like we'd also have to introduce a new predicate backend
action (like "can I edit this revision"). Given a recent discussion with
our maintainer, I'm not confident we're allowed to do that.

OK I understand.
 
> 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.

Yeah, it's going to be a choice. Sometimes editing even a commit that's
been pushed is okay (if it's on a personal branch). We already allow
doing that with 'C-x C-e', so I'd rather we only gave out a warning
(with yes-no prompt). The aforementioned predicate could do that job, too.
 
That sounds good to me. At least so that log-view-modify-change-comment works the same way as 'C-x C-e'.

reply via email to

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