Re: [RFC PATCH 0/1] making --set-upstream have default arguments

On 03/12/2021 16:03, Abhradeep Chakraborty wrote:

Philip Oakley wrote:

quoted

Can we protect the expectations of a user with a `pushDefault` setting?

Are you talking about 'push.default'? If so, then I think, the proposed
change would not affect the working of 'push.default' (if the idea is
implemented in the right way). I am adding tests to be sure about it. 

quoted

If the user has one set, then the upstream won't be where they push in a
triangular repo workflow.

Pardon me, I am unable to understand what you are trying to say. Could you
please explain a little bit?

Thanks.

In my scenario I am tracking various upstream repositories, none of
which I have push permission for. This means I have set up a
`remote.pushDefault` [1] to the remote "my", which is mapped to my
GitHub repo where I can publish work (i.e. push). 

So when I push, I am pushing to "my" remote, but when rebasing, the
upstream is not that destination, and in a collaboration environment,
may not even be the place I first forked from (e.g. the distinction
between 'git.git' [git], 'git-for-windows.git' [gfw], and Junio's repo
[gitster], all with the same root). I can then either send PRs (if
acceptable) or send patches (cover letter link to my publish repo).

In the case where a user has set their remote.pushDefault, then it's not
clear that there should be a default at all, though I maybe
misunderstanding the approach here.

Philip

[1]
https://git-scm.com/docs/git-config#Documentation/git-config.txt-remotepushDefault