| Message ID | 20211202144354.17416-1-chakrabortyabhradeep79@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | making --set-upstream have default arguments | expand |
On 02/12/2021 14:43, Abhradeep Chakraborty wrote: > To track a upstream branch from a local branch we need to pass > <repository> and <refspec> to --set-upstream (in case of git push) > or to --set-upstream-to (in case of git branch). In most cases, > users track the upstream branch with the same name as the local > branch they are currently on. For example, users most of the time > do 'git push <repository> <current_branch_refspec>'. > > So, it would be great if 'git push -u' by default do this. This > patch series address this. The patches of this patch-set set > some default values for <repository> and <refspec> if they are > not given. It first tries to get the value of <repository> from > 'branch.<current_branch>.remote'. If not then it will set the > value of <repository> as 'origin'. <refspec>'s value would be > the short name of the current branch. Can we protect the expectations of a user with a `pushDefault` setting? If the user has one set, then the upstream won't be where they push in a triangular repo workflow. Philip > > The first patch implements it for push command. However, before > moving to the 'git branch' part, it would be great to have > discussions about the proposed changes in this patch and whether > the current changes are the best way to address it or not. > > Abhradeep Chakraborty (1): > push: make '-u' have default arguments > > Documentation/git-push.txt | 6 +++++ > builtin/push.c | 48 ++++++++++++++++++++++++++++---------- > t/t5523-push-upstream.sh | 11 +++++++++ > 3 files changed, 53 insertions(+), 12 deletions(-) >
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.
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
Philip Oakley wrote: > Can we protect the expectations of a user with a `pushDefault` setting? > If the user has one set, then the upstream won't be where they push in a > triangular repo workflow. Ohh, sorry! now I understand. You are talking about 'remote.pushDefault'. I didn't think about it. Checking if the proposed change is affecting it. Thanks for pointing out!