On Thu, Oct 31, 2019 at 01:45:31PM +0000, Philip Oakley wrote:
> Hi,
> On 31/10/2019 11:30, Johannes Schindelin wrote:
> > And while we're dreaming: it would be nice to discern between "push
> > upstreams" and "base upstreams". Example: when I work on the
> > `fix-t5516-flakiness` branch, I target `upstream/master`, but I push to
> > `dscho`, i.e. my "push upstream" is `dscho/fix-t5516-flakiness`.
> >
> > Ciao,
> > Dscho
> Yep, the triangular workflow of 'publish' v 'upstream' v 'local' is quite
> tricky. There is little user facing docs for that.
>
> Many of my branches have the wrong "upstream" in the sense that it's the
> push-publish remote that holds copies of my work (i.e. I manually select the
> push-remote every time;-), even though the branches are set to track the
> original start point's upstream.
Do either of you use remote.pushDefault, branch.*.pushRemote, or
@{push}?
My triangular config for git.git looks like:
[remote "origin"]
url = https://github.com/gitster/git.git
[remote "github"]
url = https://github.com/peff/git.git
[remote]
pushDefault = github
[branch "jk/foo"]
remote = origin
merge = refs/heads/master
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.
-Peff
