On 2023-02-26 10:38 p.m., James Cook wrote:
> 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.)

So yeah, this was the first time I've decided to make such an edit 
myself. Last time I did this was on some svn repository, and the process 
there has totally escaped me. Making these kinds of changes have always 
been high on my list of things to avoid at all costs so it's not a 
practiced skill.

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

This was part of what got me into trouble. The first time I ran 
histedit, I closed out of the editor section because I had no idea what 
it was doing and it generated new commit id's which I was not expecting. 
I did this of course incorrectly and saved my unchanged file, so the 
program was happy to just run with whatever the default value is.

At this point I was kind of in the weeds, I've been using got for one 
project entirely as a demo to myself that it's working, but since I had 
now started making changes to my actual work tree it was like "back back 
peddle back peddle". Not good.

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

Right but why can you not write a script that says "hey that commit way 
back there, change that one up to the current tail". I don't get why 
it's necessary to manually back up the tree when you are specifying to 
change something in the past, it seems like that it should be a natural 
step for the tool to take to rewind the history as part of normal operation.

Said another way, if everyone always has to rewind their trees just to 
use the tool why isn't it doing that for itself.

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

Yeah I hit this too, for me, the inexperience with what was happening 
definitely reared its head. I was a little surprised to be dropped down 
to the console and immediately told it to abort since I wasn't sure what 
options even made sense to do from that point.

Again for me, I emotionally and without any idea of what's involved with 
this statement was surprised that an "edit this commit" option for 
histedit wasn't the default design choice. I see the value for the 
scripting system, especially for large numbers of commit, but I think 
the majority of use cases are going to be one-off targeted edits not 
needing the robust features there.

The behavior of the -m option also surprised me in that the tool gave me 
new ed instances for every commit in the tree all the way to the tail, 
even though I didn't want to change most of them.

-- 
Ted Bullock <tbullock@comlore.com>