On Mon, Feb 27, 2023 at 01:12:19AM -0700, Ted Bullock wrote:
> On 2023-02-26 10:38 p.m., James Cook wrote:
> > 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.

At that point, the 'histedit -l' option can be useful. It shows backups of
previous states of history, so you can "paddle back" by (re-)creating a branch
from a backed-up state. (re-creating a branch would imply first deleting it,
possibly with a command like 'got branch -r /git/myrepo.git refs/heads/main'.
and then creating it again using 'got branch -c $commit_id_shown_by_histedit_l',
then switch the work tree to the back-peddled history with 'got update -b main').

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

Many commands consider the current work tree state as part of their
input parameters. As mentioned in my other post, this is not unusual and
has been common practice in version control systems for decades.
For example, how would anyone use 'cvs update -j -j' without first updating
files to the merge target branch? Or use 'svn merge' without first updating
their working copy to the target branch? Neither CVS nor SVN provide a histedit
command (history surgery in CVS/SVN is impossible in this way), but the same
user interface concept is present.

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

From the first edited commit onwards, all commits have to be rewritten, always.
That is how Git's data model works, there is no way around it.