On Sun, Nov 03, 2019 at 05:56:04PM +0000, Philip Oakley wrote:
> > 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
