On Tue, Jul 11, 2023 at 08:29:12PM +0200, Christian Weisgerber wrote:
> Stefan Sperling:
> 
> > On Tue, May 30, 2023 at 05:10:19PM +0200, Christian Weisgerber wrote:
> > > Let's say I start "histedit" and get the default all-pick template
> > > in the editor.  Oh no, I picked a bad starting point, the commit I
> > > wanted to change isn't even in there.  So I quit the editor without
> > > touching the script... and histedit proceeds to execute it.  No
> > > harm done, I guess, but nothing accomplished either.
> > > 
> > > Should histedit simply do nothing if the script hasn't been touched?
> > > Should it fast-forward to the tip?  Would this interact poorly with
> > > anything?
> > 
> > I have noticed this as well occasionally. It hasn't bothered me, and
> > there will be a histedit backup which can be used to revert any effects
> > of such "no-op" histedits if desired.
> 
> I would suggest the same solution we use for commit messages: If
> the user exits the editor without modifying the histedit script,
> abort the operation.

Fine with me.

> > There is one use case I can think of where this behaviour is useful.
> > If you made commits with the wrong $GOT_AUTHOR info and fix $GOT_AUTHOR in
> > the environment you can then use got histedit in this way to have the
> > rewritten commits use the updated $GOT_AUTHOR value.
> 
> In which case the user can explicitly force-write the histedit
> script from the editor.

We should definitely document this trick in the man page
to give people a fighting chance of figuring this out.

> I have copied the stat & compare code from edit_logmsg() into
> histedit_run_editor(), but it doesn't work because the returned
> error is lost--see my other message. ;-)
 
Has your work on this been successfully unblocked by the EEXIST error fix?