Branches, upstreams, rebases and logistics

I was reading this thread: https://lore.kernel.org/git/YFP+KuUn99vftBIC@camp.crustytoothpaste.net/

and, in specific:

which speaks to me somewhat heavily.

As this could be a discussion forum, I'd like to see how other people are dealing with / have done for these:

I clone a repository, I do changes on top of a branch, I push for review, ... and the cycle continues until merging.

It is trivial, when native `git push/pull` is used to push/pull to/from one remote which I have access, as `pull --rebase` works magically in keeping the local state up-to-date.

It also works with the repos that you do not have direct access to push natively on the branch nowhere, as you can keep using the `pull --rebase` to sync, and "push" with some other method (`refs/for`, `git-send-email`, or others which I don't know).

However, with the Github way of working, that means: I have two remotes, (origin and upstream), on which, I develop and push on the `origin`, but I am really tracking/rebasing on/from `upstream`.

I cannot `--track` upstream, as plain `git push` won't work, and for pull, I have to separately `git fetch --all`, `git rebase upstream/<branch>`

- OR -

I have a branch, which depends on top of another branch (not yet merged upstream).

o - origin/master
 \
  o---o---o---o
  |            \
  fix/local     o--o - (fix/depends-on-local)

For brevity, I am setting "git branch --set-upstream-to=fix/local", which helps, when rebasing fix/local on top of origin/master, to rebase fix/depends-on-local on top of fix/local.

However, as noted above, a branch cannot be pushed upstream easily and have a different upstream set at the same time.

I know my logic/understanding is lacking somewhere; I am looking forward to enlightenment :-D