On 03/12/2021 16:03, Abhradeep Chakraborty wrote: > Philip Oakley wrote: > >> 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. > >> 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
