Re: git branch --edit-description a custom file

[Philip Oakley <philipoakley@iee.email>]

Hi Peff,

On 31/10/2019 15:42, Jeff King wrote:
> 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}?
I haven't been using those configs, and was only vaguely aware of them 
and what, if anything, they did (inc how to set them up _systematically_)

>
> 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

I had recently seen your <20190731055832.GA18039@sigill.intra.peff.net> 
(Wed, 31 Jul 2019 01:58:33 -0400) which mentioned your setting.
>
> 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 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).

-- 
Philip