| Message ID | 20210529071115.1908310-7-felipe.contreras@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Unconvolutize push.default=simple | expand |
Am 29.05.21 um 09:11 schrieb Felipe Contreras: > Now that the code has been simplified and it's clear what it's > actually doing, update the documentation to reflect that. > > Namely; the simple mode only barfs when working on a centralized > workflow, and there's no configured upstream branch with the same name. > > [...] > > +* `simple` - pushes the current branch with the same name on the remote. > +If you are working on a centralized workflow (pushing to the same repository you > +pull from, which is typically `origin`), then you need to configure an upstream > +branch with the same name. I'd like to remark that I personally find the following description of `push.default=simple`, taken from the git push man page [1], easier to understand: > The current branch is pushed to the corresponding upstream branch, but > as a safety measure, the push is aborted if the upstream branch does not > have the same name as the local one. [1] https://git-scm.com/docs/git-push#_description
Mathias Kunter wrote: > Am 29.05.21 um 09:11 schrieb Felipe Contreras: > > Now that the code has been simplified and it's clear what it's > > actually doing, update the documentation to reflect that. > > > > Namely; the simple mode only barfs when working on a centralized > > workflow, and there's no configured upstream branch with the same name. > > > > [...] > > > > +* `simple` - pushes the current branch with the same name on the remote. > > +If you are working on a centralized workflow (pushing to the same repository you > > +pull from, which is typically `origin`), then you need to configure an upstream > > +branch with the same name. > > I'd like to remark that I personally find the following description of > `push.default=simple`, taken from the git push man page [1], easier to > understand: > > > The current branch is pushed to the corresponding upstream branch, but > > as a safety measure, the push is aborted if the upstream branch does not > > have the same name as the local one. Except that isn't accurate. git clone $url git checkout -b fix-1 # do commits git push Does that push the current branch to the corresponding upstream branch?
Felipe Contreras <felipe.contreras@gmail.com> writes: > +If you are working on a centralized workflow (pushing to the same repository you > +pull from, which is typically `origin`), then you need to configure an upstream > +branch with the same name. I suspect it would be simpler to read and easier to understand to bring the parethesized part front, e.g. If you are pushing to the same repository you pull from (which is typically `origin`), then you need to ... as it would avoid "the project is not centralized, but I push to my own repository and pull from it---what should I do?" questions. > + > +This mode is the default since Git 2.0, and is the safest option suited for > +beginners. Nice.
Am 30.05.21 um 21:09 schrieb Felipe Contreras: >>> The current branch is pushed to the corresponding upstream branch, but >>> as a safety measure, the push is aborted if the upstream branch does not >>> have the same name as the local one. > > Except that isn't accurate. > > git clone $url > git checkout -b fix-1 > # do commits > git push > > Does that push the current branch to the corresponding upstream branch? I see. Then maybe reword to something like this: > The current branch is pushed to a branch with the same name on the > remote, but as a safety measure, the push is aborted if a corresponding > upstream branch does not have the same name as the local one. In your above example, I'm in centralized workflow, but I can still push the fix-1 branch to origin without having to configure an upstream branch for it. So this seems to contradict with the currently proposed wording: > If you are working on a centralized workflow, then you need to configure > an upstream branch with the same name.
Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@gmail.com> writes: > > > +If you are working on a centralized workflow (pushing to the same repository you > > +pull from, which is typically `origin`), then you need to configure an upstream > > +branch with the same name. > > I suspect it would be simpler to read and easier to understand to > bring the parethesized part front, e.g. > > If you are pushing to the same repository you pull from (which > is typically `origin`), then you need to ... > > as it would avoid "the project is not centralized, but I push to my > own repository and pull from it---what should I do?" questions. The top of `push.default says: Different values are well-suited for specific workflows; for instance, in a purely central workflow (i.e. the fetch source is equal to the push destination), `upstream` is probably what you want. We already brought up the central workflow, I think it's fine to reuse the concept below.
Mathias Kunter wrote: > Am 30.05.21 um 21:09 schrieb Felipe Contreras: > >>> The current branch is pushed to the corresponding upstream branch, but > >>> as a safety measure, the push is aborted if the upstream branch does not > >>> have the same name as the local one. > > > > Except that isn't accurate. > > > > git clone $url > > git checkout -b fix-1 > > # do commits > > git push > > > > Does that push the current branch to the corresponding upstream branch? > > I see. Then maybe reword to something like this: > > > The current branch is pushed to a branch with the same name on the > > remote, but as a safety measure, the push is aborted if a corresponding > > upstream branch does not have the same name as the local one. > > In your above example, I'm in centralized workflow, but I can still push > the fix-1 branch to origin without having to configure an upstream > branch for it. No, you can't: % git push fatal: The current branch fix-1 has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin fix-1 Isn't that problem the one you originally described [1]? The behavior doesn't change if you don't specify the remote: `git push` == `git push origin`. > So this seems to contradict with the currently proposed > wording: > > > If you are working on a centralized workflow, then you need to configure > > an upstream branch with the same name. My wording is correct, and that's precisely the problem. Maybe you are thinking this patch series implements the fix I proposed: it doesn't. The two patch series merely reorganizes the code to make it simpler and easier to understand. No functionality changes. Cheers. [1] https://lore.kernel.org/git/065528bf-b496-83d3-767d-2a78e50a9edf@gmail.com
Am 31.05.21 um 17:14 schrieb Felipe Contreras: >> In your above example, I'm in centralized workflow, but I can still push >> the fix-1 branch to origin without having to configure an upstream >> branch for it. > > No, you can't: > > % git push > fatal: The current branch fix-1 has no upstream branch. > To push the current branch and set the remote as upstream, use > > git push --set-upstream origin fix-1 > > Isn't that problem the one you originally described [1]? It is. > Maybe you are thinking this patch series implements the fix I proposed: > it doesn't. Yes, I thought so. Sorry for the confusion. When I asked "will your provided patch fix these failing push commands" you answered "It's not really a patch (yet), but yeah: it will". So that's why I thought so. My point simply is: For the sake of easiness of use, I think the following should work with the default settings of git: git clone $url git checkout -b fix-1 # do commits git push # should push to origin/fix-1 # others push to origin/fix-1 (but no local changes) git pull # should pull from origin/fix-1 Will this be implemented?
Mathias Kunter wrote: > Am 31.05.21 um 17:14 schrieb Felipe Contreras: > >> In your above example, I'm in centralized workflow, but I can still push > >> the fix-1 branch to origin without having to configure an upstream > >> branch for it. > > > > No, you can't: > > > > % git push > > fatal: The current branch fix-1 has no upstream branch. > > To push the current branch and set the remote as upstream, use > > > > git push --set-upstream origin fix-1 > > > > Isn't that problem the one you originally described [1]? > > It is. > > > Maybe you are thinking this patch series implements the fix I proposed: > > it doesn't. > > Yes, I thought so. Sorry for the confusion. When I asked "will your > provided patch fix these failing push commands" you answered "It's not > really a patch (yet), but yeah: it will". So that's why I thought so. I have not yet sent the patch to change the current behavior. First I sent a bunch of patches to reorganize the code so it's more clear what it's actually doing. Once those patches are merged, then I will probably send the one to change the behavior. I will include you in the Cc list when I do so. > My point simply is: For the sake of easiness of use, I think the > following should work with the default settings of git: > > git clone $url > git checkout -b fix-1 > # do commits > git push # should push to origin/fix-1 > # others push to origin/fix-1 (but no local changes) > git pull # should pull from origin/fix-1 I agree. > Will this be implemented? It's hard do say, but it probably won't. All my suggestions for improvement are mostly disregarded, and considering *nobody* has said a word about whether or not the current behavior makes sense, I don't think there are very good chances of changing it. Consider my last mail "git push default doesn't make sense" [1]: nobody replied. But maybe that's my fault, because even though I broke the In-Reply-To in order to start a new thread, it seems mail handling software still uses References (incorrectly IMO). So maybe if I start a new thread completely fresh people will notice, and reply. I will do so with a patch once I'm done with the reorganization. In my experience you need to convince either Junio Hamano, or Jeff King for any change in behavior to happen, and until they do comment on this one it's fair to say it won't happen. Cheers. [1] https://lore.kernel.org/git/60b15cd2c4136_2183bc20893@natae.notmuch/
Am 31.05.21 um 19:31 schrieb Felipe Contreras: > Once those patches are merged, then I will probably send the one to > change the behavior. > > I will include you in the Cc list when I do so. Thank you very much. > In my experience you need to convince either Junio Hamano, or Jeff King > for any change in behavior to happen, and until they do comment on this > one it's fair to say it won't happen. I assume they are on this mailing list? I'd say it should be quite an argument if the related StackOverflow question dealing with this exact issue is one of the top-voted git questions of all time. [1] It seems that millions of developers (judging by the number of views of that question) wonder what they need to do so that "git pull and git push will work immediately" on a newly created local branch. If that would "just work" out of the box and with the default settings of git, without having to read up the solution in StackOverflow first, then it would certainly be an improvement for a huge number of people. So, to all whom it may concern, I think a behavioral change is advisable here. Thank you. [1] https://stackoverflow.com/q/2765421
Mathias Kunter wrote: > Am 31.05.21 um 19:31 schrieb Felipe Contreras: > > Once those patches are merged, then I will probably send the one to > > change the behavior. > > > > I will include you in the Cc list when I do so. > > Thank you very much. > > > In my experience you need to convince either Junio Hamano, or Jeff King > > for any change in behavior to happen, and until they do comment on this > > one it's fair to say it won't happen. > > I assume they are on this mailing list? Of course, and they are also on the Cc list of this mail. > I'd say it should be quite an argument if the related StackOverflow > question dealing with this exact issue is one of the top-voted git > questions of all time. [1] That seems to be a different issue. Related, but not quite the same. That question is answered at the time the user tries to make a push: fatal: The current branch fix-1 has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin fix-1 That's literally the top answer in SO. > It seems that millions of developers (judging by the number of views of > that question) wonder what they need to do so that "git pull and git > push will work immediately" on a newly created local branch. Yes, probably many people do wonder that, but not necessarily all of them (at least of the ones that participatd in that SO question). > If that would "just work" out of the box and with the default settings > of git, without having to read up the solution in StackOverflow first, > then it would certainly be an improvement for a huge number of people. I agree, but I have already tried to improve the interface in a number of ways to no avail. Inertia is a powerful force. We'll see how this one goes. Cheers.
Am 31.05.21 um 23:15 schrieb Felipe Contreras: >> I'd say it should be quite an argument if the related StackOverflow >> question dealing with this exact issue is one of the top-voted git >> questions of all time. [1] > > That seems to be a different issue. Related, but not quite the same. Well, what the OP actually wanted to know there is "how can I use git pull and git push on a new local branch". The OP knows it can be done by configuring an upstream branch, and therefore he also specifically asks about the details of how to do that. > We'll see how this one goes. Thank you for your efforts.
Felipe Contreras <felipe.contreras@gmail.com> writes: >> I suspect it would be simpler to read and easier to understand to >> bring the parethesized part front, e.g. >> >> If you are pushing to the same repository you pull from (which >> is typically `origin`), then you need to ... >> >> as it would avoid "the project is not centralized, but I push to my >> own repository and pull from it---what should I do?" questions. > > The top of `push.default says: > > Different values are well-suited for specific workflows; for instance, > in a purely central workflow (i.e. the fetch source is equal to the > push destination), `upstream` is probably what you want. > > We already brought up the central workflow, I think it's fine to reuse > the concept below. Oh, thanks for finding another instance to be corrected. Even in that sentence, the more important point is that upstream would be appropriate if you push to the same place as you fetch from, and we do not have to say "purely central" at all.
Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@gmail.com> writes: > > >> I suspect it would be simpler to read and easier to understand to > >> bring the parethesized part front, e.g. > >> > >> If you are pushing to the same repository you pull from (which > >> is typically `origin`), then you need to ... > >> > >> as it would avoid "the project is not centralized, but I push to my > >> own repository and pull from it---what should I do?" questions. > > > > The top of `push.default says: > > > > Different values are well-suited for specific workflows; for instance, > > in a purely central workflow (i.e. the fetch source is equal to the > > push destination), `upstream` is probably what you want. > > > > We already brought up the central workflow, I think it's fine to reuse > > the concept below. > > Oh, thanks for finding another instance to be corrected. In fact there's many: This mode only makes sense if you are pushing to the same repository you would normally pull from (i.e. central workflow). > Even in that sentence, the more important point is that upstream would > be appropriate if you push to the same place as you fetch from, and we > do not have to say "purely central" at all. Actually, I forgot the main reason I decided to rename centralized to same_repo: they are not the same thing. You can have a decentralized workflow where you have multiple repositories configured, but every branch pulls and pushes to the same repository (to them, not other branches): hotfix <-> dayjob/production cleanups <-> upstream/master experiment-1 <-> personal/experiment-1 So it's more like: centralized = ~decentralized triangular = ~two-way A centralized workflow consists of a single repository where branches are typically two-way, but not necessarily. A decentralized workflow consists of multiple repositories where branches are typically triangular, but not necessarily. So the triangularity is per branch, not per repository, and same_repo means a two-way branch, could be a centralized or decentralized workflow. Therefore your proposal: If you are pushing to the same repository you pull from (which is typically `origin`), then you need to ... is actually better, I just had to remind myself that centralized and same repo are not the same thing. Of course it would help to have a place in Documentation/ where trianguar and centralized are explained. Cheers.
On 01/06/2021 13:12, Felipe Contreras wrote: > So it's more like: > > centralized = ~decentralized > triangular = ~two-way > > A centralized workflow consists of a single repository where branches > are typically two-way, but not necessarily. > > A decentralized workflow consists of multiple repositories where > branches are typically triangular, but not necessarily. > > So the triangularity is per branch, not per repository, and same_repo > means a two-way branch, could be a centralized or decentralized > workflow. My personal viewpoint is that triangular flow happens when you cannot push to the repo you consider as upstream. Rather you typically have a publish/backup repo instead (semi-public, semi-private - few are interested ;-). That (can't push one way around the triangle) part of the flow is separate from the distinction between patch flows and merge (Pull) request flows. E.g. My personal Git repo can be triangular with both git.git and git-for-windows, plus a few (what I view as) fetch-only repos from other collaborators/maintainers beyond the triangular 'golden' upstream repo. I often consider GitHub as a centraliser, but I don't think it's what is being considered above. -- A thought did come to mind that a Git serve/repo (typically bare) should be able to offer a 'refs/users/*' space (c.f. refs/remotes used by individual users) that allows a type of 'centralised' operation (almost as if all the users used a common alternates repo). Users could only push to their own /user refs, but could pull from the main refs/heads, and their own refs/users/ space. This would give flexibility to smaller corporate central operations to offer 'triangular flow' where each dev would feel like they have their own 'push' repo, when in reality it's really personalised branches. As usual the authentication of user names being handed off elsewhere;-). It could avoid some of the --alternate management aspects. It's a thought.. -- Philip
Philip Oakley wrote: > On 01/06/2021 13:12, Felipe Contreras wrote: > > So it's more like: > > > > centralized = ~decentralized > > triangular = ~two-way > > > > A centralized workflow consists of a single repository where branches > > are typically two-way, but not necessarily. > > > > A decentralized workflow consists of multiple repositories where > > branches are typically triangular, but not necessarily. > > > > So the triangularity is per branch, not per repository, and same_repo > > means a two-way branch, could be a centralized or decentralized > > workflow. > My personal viewpoint is that triangular flow happens when you cannot > push to the repo you consider as upstream. It's not about permissions. Even if I had permissions to push to git.git, I wouldn't do so. I do have permission to push to some public projects, but I instead send patches/pull requests like everyone else. It's more about ownership. In my personal repositories I can push whatever I want, but on shared repositories I have to be more careful. > Rather you typically have a publish/backup repo instead (semi-public, > semi-private - few are interested ;-). > > That (can't push one way around the triangle) part of the flow is > separate from the distinction between patch flows and merge (Pull) > request flows. I think it's not separate, that is the thing that makes a triangular flow triangular: the flow of patches goes through a different repository, and then they get picked and merged into the upstream one. > E.g. My personal Git repo can be triangular with both git.git and > git-for-windows, plus a few (what I view as) fetch-only repos from other > collaborators/maintainers beyond the triangular 'golden' upstream repo. > > I often consider GitHub as a centraliser, but I don't think it's what is > being considered above. GitHub is all about pull requests, you fork a repository, you push your branch into that personal fork, and then you request a pull from upstream. That's triangular. > -- > A thought did come to mind that a Git serve/repo (typically bare) should > be able to offer a 'refs/users/*' space (c.f. refs/remotes used by > individual users) that allows a type of 'centralised' operation (almost > as if all the users used a common alternates repo). Users could only > push to their own /user refs, but could pull from the main refs/heads, > and their own refs/users/ space. > > This would give flexibility to smaller corporate central operations to > offer 'triangular flow' where each dev would feel like they have their > own 'push' repo, when in reality it's really personalised branches. As > usual the authentication of user names being handed off elsewhere;-). It > could avoid some of the --alternate management aspects. > > It's a thought.. Yeah, and interesting thought. But it demonstrates what I said above: you can have a central repository, and yet have triangular branches: feature-1 <= origin/master => origin/felipec/feature-1 Cheers.
Felipe Contreras <felipe.contreras@gmail.com> writes: > Therefore your proposal: > > If you are pushing to the same repository you pull from (which is > typically `origin`), then you need to ... > > is actually better, I just had to remind myself that centralized and > same repo are not the same thing. Yes, that is exactly why I brought up >> as it would avoid "the project is not centralized, but I push to my >> own repository and pull from it---what should I do?" questions. as a reason why we want to phrase it that way, so we are on the same page ;-)
On 01/06/2021 17:35, Felipe Contreras wrote: > Philip Oakley wrote: >> On 01/06/2021 13:12, Felipe Contreras wrote: >>> So it's more like: >>> >>> centralized = ~decentralized >>> triangular = ~two-way >>> >>> A centralized workflow consists of a single repository where branches >>> are typically two-way, but not necessarily. >>> >>> A decentralized workflow consists of multiple repositories where >>> branches are typically triangular, but not necessarily. >>> >>> So the triangularity is per branch, not per repository, and same_repo >>> means a two-way branch, could be a centralized or decentralized >>> workflow. >> My personal viewpoint is that triangular flow happens when you cannot >> push to the repo you consider as upstream. > It's not about permissions. Even if I had permissions to push to git.git, > I wouldn't do so. I do have permission to push to some public projects, but I > instead send patches/pull requests like everyone else. I had it that if you don't have permissions then you definitely need to use a Triangular flow. Hence how I was presenting the view. > > It's more about ownership. In my personal repositories I can push > whatever I want, but on shared repositories I have to be more careful. True, there are social choices that are equivalent to a type of 'permission'. > >> Rather you typically have a publish/backup repo instead (semi-public, >> semi-private - few are interested ;-). >> >> That (can't push one way around the triangle) part of the flow is >> separate from the distinction between patch flows and merge (Pull) >> request flows. > I think it's not separate, that is the thing that makes a triangular > flow triangular: the flow of patches goes through a different repository, > and then they get picked and merged into the upstream one. Pull requests can do the same thing, just as in Git-for Windows.. > >> E.g. My personal Git repo can be triangular with both git.git and >> git-for-windows, plus a few (what I view as) fetch-only repos from other >> collaborators/maintainers beyond the triangular 'golden' upstream repo. >> >> I often consider GitHub as a centraliser, but I don't think it's what is >> being considered above. > GitHub is all about pull requests, you fork a repository, you push your > branch into that personal fork, and then you request a pull from > upstream. > > That's triangular. Yes. > >> -- >> A thought did come to mind that a Git serve/repo (typically bare) should >> be able to offer a 'refs/users/*' space (c.f. refs/remotes used by >> individual users) that allows a type of 'centralised' operation (almost >> as if all the users used a common alternates repo). Users could only >> push to their own /user refs, but could pull from the main refs/heads, >> and their own refs/users/ space. >> >> This would give flexibility to smaller corporate central operations to >> offer 'triangular flow' where each dev would feel like they have their >> own 'push' repo, when in reality it's really personalised branches. As >> usual the authentication of user names being handed off elsewhere;-). It >> could avoid some of the --alternate management aspects. >> >> It's a thought.. > Yeah, and interesting thought. But it demonstrates what I said above: > you can have a central repository, and yet have triangular branches: I see triangular being about repos, rather than branches. The suggestion about was, essentially, about managing multiple user forks on the same server without using alternates etc. It's not fully thought through ;-) > > feature-1 <= origin/master > => origin/felipec/feature-1 > > Cheers. > I expect to be off-line for a week or so. Philip
Philip Oakley wrote: > On 01/06/2021 17:35, Felipe Contreras wrote: > > Philip Oakley wrote: > >> On 01/06/2021 13:12, Felipe Contreras wrote: > >>> So it's more like: > >>> > >>> centralized = ~decentralized > >>> triangular = ~two-way > >>> > >>> A centralized workflow consists of a single repository where branches > >>> are typically two-way, but not necessarily. > >>> > >>> A decentralized workflow consists of multiple repositories where > >>> branches are typically triangular, but not necessarily. > >>> > >>> So the triangularity is per branch, not per repository, and same_repo > >>> means a two-way branch, could be a centralized or decentralized > >>> workflow. > >> My personal viewpoint is that triangular flow happens when you cannot > >> push to the repo you consider as upstream. > > It's not about permissions. Even if I had permissions to push to git.git, > > I wouldn't do so. I do have permission to push to some public projects, but I > > instead send patches/pull requests like everyone else. > > I had it that if you don't have permissions then you definitely need to > use a Triangular flow. Hence how I was presenting the view. If you don't have permissions you have no option but a triangular flow. If you are in a triangular flow that doesn't necessarily mean you don't have permissions. > >> A thought did come to mind that a Git serve/repo (typically bare) should > >> be able to offer a 'refs/users/*' space (c.f. refs/remotes used by > >> individual users) that allows a type of 'centralised' operation (almost > >> as if all the users used a common alternates repo). Users could only > >> push to their own /user refs, but could pull from the main refs/heads, > >> and their own refs/users/ space. > >> > >> This would give flexibility to smaller corporate central operations to > >> offer 'triangular flow' where each dev would feel like they have their > >> own 'push' repo, when in reality it's really personalised branches. As > >> usual the authentication of user names being handed off elsewhere;-). It > >> could avoid some of the --alternate management aspects. > >> > >> It's a thought.. > > Yeah, and interesting thought. But it demonstrates what I said above: > > you can have a central repository, and yet have triangular branches: > > I see triangular being about repos, rather than branches. If you have a feature-1 branch that fetches from origin, rebases onto origin/master, but pushes to origin/feature-1... Does that qualify as triangular?
diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt index f2667b2689..632033638c 100644 --- a/Documentation/config/push.txt +++ b/Documentation/config/push.txt @@ -24,15 +24,14 @@ push.default:: * `tracking` - This is a deprecated synonym for `upstream`. -* `simple` - in centralized workflow, work like `upstream` with an - added safety to refuse to push if the upstream branch's name is - different from the local one. +* `simple` - pushes the current branch with the same name on the remote. + -When pushing to a remote that is different from the remote you normally -pull from, work as `current`. This is the safest option and is suited -for beginners. +If you are working on a centralized workflow (pushing to the same repository you +pull from, which is typically `origin`), then you need to configure an upstream +branch with the same name. + -This mode has become the default in Git 2.0. +This mode is the default since Git 2.0, and is the safest option suited for +beginners. * `matching` - push all branches having the same name on both ends. This makes the repository you are pushing to remember the set of
Now that the code has been simplified and it's clear what it's actually doing, update the documentation to reflect that. Namely; the simple mode only barfs when working on a centralized workflow, and there's no configured upstream branch with the same name. Cc: Elijah Newren <newren@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> --- Documentation/config/push.txt | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-)