Another look?

[Harald Nordgren <haraldnordgren@gmail.com>]

> 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