vr8hub
commented
1 month ago Every rebase is different, and this one is especially different. :) So some of this can be trial and error, even once you understand the basics of rebasing. Thus, the first rule of rebase: MAKE A COPY OF THE LOCAL REPOSITORY BEFORE BEGINNING! That way if anything happens, you can just copy over the backup and try again.
Note that at any point, you can type git rebase --abort at the command line, and it will abort the rebase, putting the repository back in the state it was in before you started the rebase. If things are so messed up that that doesn't work, that's what you have a backup for. :)
The gist of a rebase is: start the rebase at the commit ID before the one you want to affect, make whatever changes need to be made to that commit, then finish (continue) the rebase.
In this particular case, the sequence of events we care about is: commit 2: Deleted body.xhtml commit 3: Copied over the split files and then ran typogrify on those files.
The problem is that the two things done in commit 3 can't be separated. We can't "unrun" typogrify. So, the only alternative is to re-split the files and commit them as part of step 1, then git magic will mean that step 2 only contains the typogrify. (Git stores the difference between the last commit and the current one, so when the step 1 commit changes to include the files, then the step 2 commit will "automatically" only contain the typogrify.)
What makes this one a little bit special is that we have to "undo" the delete of body.xhtml in step 1 in order to re-split the files. So, again, after having MADE A BACKUP OF THE LOCAL REPOSITORY:
- From the command line at the root directory of the repository, do a
git log --onelineto see a list of all the commits. You want the commit ID of the first commit (since it's the second commit we want to change). In this case, that is 6f4b48a. - Start the rebase with
git rebase -i 6f4b48a. (You can type--interactiveif you want typing practice.) - This will open up a vim window with a list of all the commits with the cursor on the top one, which will be the second commit, the one we want to change. If you know how to use vim, then you want to change the "pick" on the first line to "edit". If you don't know how to use vim, you should learn the basics of that, too. :) Type
ito go into insert mode, use the forward delete key (if you have a full-size keyboard, the one under fn, not the one next to =) to delete the four letters in "pick," then type "edit". - Exit the vim window with
Esc :wq Enter. - This will drop you back at the command prompt.
- The state of the repository is after the second commit, which deleted body.xhtml. But we don't want that delete to happen. So we have to undo the commit, and then undo the delete.
- To undo the commit, type
git reset HEAD~. This undoes the last commit, but leaves the changes that were made (in this case, the delete). - To undo the delete, type
git restore src/epub/text/body.xhtml. - Now you have to do all of the things you did to cleanup body and do the split. It's important that the body and split files look exactly like they did the first time; if not, the differences between commit 2 and commit 3 are going to involve more than just the typogrify, and we don't want that. I'm guessing that shouldn't be too hard; I assume you just removed the PG stuff, put in the markers, than ran the split. This is again why we have a backup; if it turns out there are other changes you missed, you can start over and do it again, picking up those changes.
- Once you're done, move the split files into the
src/epub/textdirectory. - You have both body.xhtml and the split files in the directory. Now you can delete body.xhtml.
- Run
se clean. - Do a
git add -Aand then agit commit -m "Split files and clean". This now puts us where our commit message said we were—we've split the files, run clean, and gotten rid of the original body.xhtml. - Now we want to hand things back over to rebase to complete everything else. You do this with
git rebase continue. If everything worked, this should rewind all of the remaining commits, and your repository is now good, with the first three commits containing what the messages say they contain. - You can now make the other changes locally that need to be made from the review.
- When you're finished and want to push everything to GitHub, you'll have to do a force push, since we've changed history with the rebase. This is done by adding
-fto the git command, i.e.git push -f origin main.
Good luck! Let me know (here) if you have any other questions or run into any problems.
bobrk
<i>to<em>isn't really adding semantics.) It's better to have the commit message reflect what's happening in the commit as closely as possible. Just make a note for the future, no need to change this one.<em>tagged words/phrases to find the ones that should be tagged differently or not tagged at all.<p>should have the "continued" class.And for the big finale (sorry):