Ted Bullock <tbullock@comlore.com> writes:
> On 2023-02-26 6:14 p.m., Ted Bullock wrote:
>> Hiya folks,
>> 
>> So I attempted to use got histedit this evening to change a significant
>> typo in a commit message. So far, I've read through the manual on this
>> and I'm left barely ahead but definitely without an edited commit message.
>
> Sorry for spamming the list with the double send.
>
> It took me another hour and a half of making mistakes with the histedit
> command to finally get it to behave and adjust the repository in a sane
> way. It was not at all obvious even when looking at the manual to make
> the adjustment and then I mistakenly edited the wrong commit at least 3
> times. There was woefully little UI guidance about what I was doing
> wrong as well and what changes could be made. Of course relearning ed
> for the umpteenth time did contribute here somewhat.
>
> I did eventually read closer and find the -m option, but by then I had
> some grasp of the scripting system.
>
> So in summary I'm not sure if it's just the documentation, my reading
> comprehension or the tool itself being obtuse in this regard but I found
> using it to edit exceedingly challenging.
>
> -- 
> Ted Bullock <tbullock@comlore.com>

I was curious about this so just have got histedit a try. Just reporting
on my experience here.

The process made sense to me, but to be fair, I've seen a very similar
ui before both in mercurial's histedit command and git's rebase -i, so I
already knew what to expect. (I have one mild complaint, at the end.)

One question for you: you used ed in the example, but when you were
experimenting, did you use a visual editor, or begin with a 1,$p to see
what was already in the file? It began in my case with a sequence of
"pick" commands implementing the "no-op" script which, if left unedited,
would have (I think) left my history unchanged. So I'm confused why you
changed it by adding things on to the end; didn't that cause got to
complain about a commit listed twice in the script?

> 1. Why is it necessary to backup to an arbitrary point in the tree to
> run this? From a user perspective this is weird for me, like if you want
> me to write a program to edit the history, let me specify that in the
> program.

This makes intuitive sense to me: you have to tell got which part of
history you'd like to edit, by selecting a starting and ending point in
history. The end point is the branch tip, and you choose the start point
with got update -c. But, again, I have a head start here because I was
already familiar with the process in hg and git.

One minor complaint: I tried using the "edit" command, which the man
page says will make got interrupt the process for amending. I wasn't
entirely sure how I was supposed to amend the commit. I seem to have
guessed right the first time, though: to "amend" the commit I actually
have to create it again with "got ci". In other VCSs I'm used to the old
log message being available when "amending" but it wasn't, but I guess
that's a matter of polish. Then once I'm done I have to run got histedit
-c. The sequence of steps (1. create script with "edit"; 2. got ci; 3.
got he -c) is never explicitly laid out, and arguably step 2 is not
documented at all. But I pieced it together without much trouble.

-- 
James