From: Stefan Sperling Subject: Re: No-op histedit scripts To: Christian Weisgerber Cc: gameoftrees@openbsd.org Date: Fri, 14 Jul 2023 17:26:08 +0200 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?