From: Christian Weisgerber <naddy@mips.inka.de>
Subject: Re: No-op histedit scripts
To: gameoftrees@openbsd.org
Date: Tue, 11 Jul 2023 20:29:12 +0200

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.

> 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.

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. ;-)

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de