Thread (6 messages) flat view 6 messages, 4 authors, 2026-01-12

Re: Another look?

From: D. Ben Knoble <hidden>
Date: 2026-01-05 21:55:39

On Thu, Jan 1, 2026 at 6:38 PM Harald Nordgren [off-list ref] wrote:
quoted
Again this seems to do a "step 1 goes in a direction, step 2 fixes
its mistake, step 3 changes course" drunken-man's walk.

The same advice to restructure them into a logical incremental
progression that moves the codebase in one consistent direction to
eventually reach the goal at the end applies.
Isn't programming always bit of drunken-man's walk?

I'm very hesitant to restructure my history before I am confident I will
not need any of the old work later -- I would hate to lose history if I
make a mistake.

One option is to keep my code backed up on a separate branch locally, but
Git will already do this, more or less! See "git reflog". No need to worry :)

I don't fear-driven development to lead to optimal results ;)
As a side-note: In my day job we only allow "squash and merge" on our
GitHub. This gives devs the flexibility to treat their branches as a WIP
area before merging, but still gives a pristine git history after merge.
This feels to me like a good trade-offs. But again, happy to take
instructions on how to do better.
I think others have covered this, but you can both "branch is WIP" and
"clean history" by iterating within a PR. The GitHub UI does not make
this particularly nice [1], but my recipe is essentially

1. Make changes
2. Post range-diff [2] and force-push

[1]: https://benknoble.github.io/blog/2025/03/17/more-range-diff/
[2]: https://benknoble.github.io/blog/2024/10/04/copy-range-diff/

-- 
D. Ben Knoble
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help