Another look?

From: Harald Nordgren <haraldnordgren@gmail.com>
Date: Jan 1, 2026, 23:38 UTC
Message-ID: <20260101233839.17639-1-haraldnordgren@gmail.com>
In-Reply-To: <xmqqh5t5c4lj.fsf@gitster.g>

Show 6 quoted lines

> 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 this gets problematic as I add more work (endless cherry-picking and squashing) between local branches before submitting new patches. So now you know some of my reasoning. I'm not saying I'm right, but it's a bit fear-based.

With that said, my idea has always been to squash everything into a single commit before merging this. The whole diff is not that big. I can split it into code in one commit and tests in another.

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 see you are now using pushremote_for_branch() that is already used
> by branch_get_push().  If that gives us "the other thing" that we
> would want to compare, instead of adding yet another configuration
> variable users need to be aware of, that is really good.

Thanks for the encouragement! I put a lot of work into the tests as well, I hope they tell the story of what this code achieves now.

Harald