On Sun, Nov 03, 2019 at 05:56:04PM +0000, Philip Oakley wrote:

quoted

Then upstream comparisons, "git rebase" etc without arguments, do what I
want: compare against master. And "git push" without arguments does what
I want: push this branch to my fork. And if I need to refer to the
pushed version for some reason (e.g., comparing what I just changed to
what I last sent out, "git range-diff @{u} @{push} HEAD" does the right
thing.

I am trying to write myself some 'user' based notes covering the
publish-backup-collaborate-upstream viewpoints of the different repo
settings as the config pages rarely give that viewpoint (hence my bad
setup).

There's also still the 'triangle' workflow to clarify - does it refer to
patch based flow, or to a three-way repo config?

I think it's solely about the three-way repo config. The key thing is
that "somehow" the commits I push to my fork end up in the upstream
repository. In git.git, that happens via the mailing list workflow. But
in projects based on GitHub, it's cross-fork pull requests. I guess in a
project like linux.git, it could even via real "git pull" commands.

But in any of those cases, the config I showed would be what you want.
(I forgot to show that I also set push.default to "current", since the
default "simple" wouldn't make much sense).

I suspect there are more configs that need setting up for a proper stable
user experience (e.g. the merge setting of '--ff-only' when the local branch
"--follow"s the upstream but should never have local changes).

Possibly. I don't actually keep a regular "master" branch in my local
clone. I use "origin/master" as the upstream base for my branches, and
for when I need to test the current vanilla behavior to reproduce a bug
(I just "git checkout origin/master" and work on a detached HEAD).

If you did keep such a branch, though, then yeah, I think you'd want to
use --ff-only, because it's just tracking upstream.

-Peff