GNU bug report logs -
#38343
27.0.50; vc git: Cannot edit outgoing log (like git commit --amend)
Previous Next
Reported by: Fredrik Nyqvist <fredrik.nyqvist94 <at> gmail.com>
Date: Sat, 23 Nov 2019 10:03:01 UTC
Severity: normal
Tags: patch
Found in version 27.0.50
Fixed in version 31.1
Done: Sean Whitton <spwhitton <at> spwhitton.name>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On 27.11.2019 22:11, Fredrik Nyqvist wrote:
>
>
> Den ons 27 nov. 2019 kl 01:10 skrev Dmitry Gutov <dgutov <at> yandex.ru
> <mailto:dgutov <at> yandex.ru>>:
>
> On 26.11.2019 22:43, Fredrik Nyqvist wrote:
> > Den mån 25 nov. 2019 kl 23:49 skrev Dmitry Gutov
> <dgutov <at> yandex.ru <mailto:dgutov <at> yandex.ru>
> > <mailto:dgutov <at> yandex.ru <mailto:dgutov <at> 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.
> 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.
This bug report was last modified 76 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.