Folding intermediate commits into later commits, not earlier

Question

Suppose I have three commits

A --> B' --> B

Commit B' represents an intermediate state, where work is unfinished and tests aren't passing. I may have made commit B' in order to switch from working on my home machine to my work machine.

Let's say I'm on a topic branch that no one is looking at but me. But all three commits are in the remote, otherwise I couldn't use B' to pass changes from one machine to another.

If I do git rebase -i <commit-before-A> (or if A is the first commit, then git rebase i --root), and I choose to fixup or squash commit B', then the changes in B' will be folded into commit A.

But this isn't appropriate. I want commits A and B to to represent reasonable checkpoints in the work, where changes aren't in a half-assed state that no one would understand but me. If I fixup the B' commit, then that will leave commit A with the half-baked changes that B' used to have. I want commit B' to be folded into B, since B' represented intermediate work towards commit B.

Possible solutions:

1a. Just leave commit B' and name it "dummy commit" so no one pays attention to it. It's on my topic branch (even though it's pushed to remote), so who cares.

1b. If I think people might potentially look at my current topic branch and judge me for being unprofessional, give B' its own branch that I'm sure no one cares about, then as soon as B is ready, commit it and merge it back into the original branch, then delete the temporary branch. So it looks like

  BRANCH DELETED
  B' --> B''
 /         \
A ---------> B
 BRANCH REMAINING

2. Get rid of B' before I make commit B. So if B' was made in order to switch machines, once I get to the other machine, immediately git reset --soft, then once I've finished changes, make commit B, then git push --force to the remote, then if and when I go back to the first machine, use git pull --force. It's unfortunate to "rewrite history" this way, and using --force quite so often seems like a dangerous habit.
3. drop commit B' instead of squash or fixup. Git seems to not treat this very intelligently and require merge resolutions even when A --> B' --> B are evidently fast-forward changes. Again, you're rewriting history, and --force will be required multiple times.
4. If the two machines are on the same network, use file sharing instead. This seems gross to me and not flexible.
5. Do one of these and live with it; it's a matter of taste and you can't please everyone.

Bear in mind the purpose of this question isn't to start an argument on a matter of taste; it's to uncover pros and cons I haven't thought of, or expose me to options I haven't thought of.

Related posts:

• Is it possible to push a git stash to a remote repository?
• Git commit not finished but can't continue on that machine
• Should I use git stash to save ongoing changes of my project and push it to github to access in other computers?
• When to commit code?

Answer 1

Use git rebase -i to squash B into B'. Use the squash instruction so that you get an opportunity to edit the commit message.

After the operation, others (and you) will only see a new commit B", and B and B' will soon be forgotten, and you do not have to worry that you "cheated" and folded B into B' instead of the other way round.

Of course, you will have to force-push the branch, but that does not matter, as you said, you are the only one looking at it. Under these circumstances, frequent force-pushing is not bad habit at all.