On Sat, Apr 23, 2022 at 6:44 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Tao Klerks <tao@xxxxxxxxxx> writes: > > >> "none", probably. Much better than "current" that can create new > >> branches on the other side, which you would want to do with an > >> explicit end-user instruction (i.e. not with "git push", but with > >> "git push origin topic"). > > Sorry, "nothing" was what I meant. Those non-simple branches are > left unconfigured with ASU=simple. We both agree that the user does > not want to see the "with push.default=simple you have, you cannot > push from it" but the reason why they do not want to see can be > multiple. You are assuming that they want to push to somewhere > else. I am taking into account that they may not want to push them > at all, but only use locally. If the intended workflow is > > git checkout -b main [origin/main] ;# assuming DWIM is on > git checkout -b topic origin/main > ... work work work ... > git checkout main > git merge topic > ... test test test ... > ... ahh, no it does not work, back to fix topic ... > git reset --hard ORIG_HEAD > git checkout topic > ... work work work ... > git rebase -i ... > git checkout main > git merge topic > ... test test test ... > ... yay, this time it is perfect and we can push it out ... > git push (two interesting/surprising things here: 1) The user chooses to merge to master *before* testing (does not test on topic) 2) The user does not use CI pipelines of any kind ) > > i.e. matching "simple" branches like main are used to locally bundle > what you locally worked on, and the result is pushed out to the > other side from there, while non-simple branches like topic are used > to locally work on your real changes, it is reasonable to expect > that the user wants "git push" to fail when the 'topic' branch is > checked out. I would argue that the user who wants push to fail here is a very rare user. Presumably they thought they were somewhere else, and the "git push" was a complete mistake? (why else would you run the command??) For users of a central repo (github, gitlab, bitbucket, teamhub, etc etc) when they say "git push" it is normally/typically to, well... push their changes to the remote! To back them up because they're worried about losing them, or to share them with teammates/collaborators, to run CI, or for any other reason. I'm not arguing that "nothing" is useless to everyone, but I am arguing that for the workflow you have highlighted above, "nothing" is not a valuable setting. It provides close to no practical safety benefits, and makes pushing shared branches much more awkward. > > But unfortunately that does not work at the last step, as "nothing" > unfortunately affects the last step that tries to check out 'main', > too. push.default='simple' would make it work. > OK > > I would argue that git generally has a "problem", in that > > "branch.XXX.merge" entries have two classes of > > meanings/interpretation: > > * That is the "parent branch" > > ** The one I want changes from, when I say "update me with changes" > > ** The one I eventually want to get my changes to > > * That is the "remote instance/address" of *this* branch > > ** If I pull, it's to get changes to the same branch that others might have made > > ** When I push, it's to get this branch onto the server (not to get my > > changes into the "upstream") > > Yes, that is very well known, and there arey mechanisms to support > some workflows that separates "where I get changes from" and "where > I publish my work" (look for "triangular workflows" in the list > archive). Yes, the best/simplest summary I've seen so far is the github blog post https://github.blog/2015-07-29-git-2-5-including-multiple-worktrees-and-triangular-workflows/ In the particular model highlighted there, you use "branch.XXX.merge" entries to indicate "the parent branch" while keeping the "remote branch instance" separate, by leveraging the "push.default=current" setting, but of course this "parent branch" information is still local-only, and you cannot collaborate on your feature/topic branch with others. If someone else checks out your topic branch from your server and pushes some changes to it, then your flow breaks, because your "git pull" means "bring in changes from the parent", not "bring in any changes that might have occurred on the topic branch". I understand there are techniques/flows that users can choose to use, but I don't think this changes the fundamental and, for beginners, problematic, ambiguity of meaning of "branch.XXX.merge". The "branch.autosetupmerge=simple" proposal is to simplify it down to "branch.XXX.merge entries indicate what the remote instance of this branch is, and will normally be aligned with the name of the local branch". This "simplification" is incompatible with the particular triangular workflow highlighted above. > > > In suggesting the user could/should have done that (in order to get a > > sane workflow, presumably), you are also suggesting that they should > > keep the state of that "local version of the upstream they eventually > > want to get their changes into" up-to-date: They should first check > > out master (for example), pull on master to get the state they expect, > > and *then* create their new differently-named local branch. > > FWIW, I am not. Fair enough, sorry I misunderstood. What I meant is that you need to "maintain" your local master when you do eventually want to push up any topic branch, *and* any other time you do want to "catch up" with upstream changes; assuming you work on multiple topic branches in parallel (which is one of the "superpowers" of git), the local master has lots of different reasons to change. > > I do not think it is healthy nor necessary to make your local work > "catch up" too often with the outside world unnecessarily, be it > done with rebase or with merge. They _can_ update 'master' when > outside world has something worth adding to your topic extra > dependency on and then update 'topic' to include what you took to > 'master' from the outside. Dissociating the 'topic' from outside > world is one way to encourage a better workflow. On this we agree, I guess :) I will have another go at proposing a complete, easy-to-understand, easy-to-enter, "simple" workflow that emphasises local and remote branch "correspondence" by encouraging "branch.XXX.merge" to always and automatically be set to the same-name branch on the remote (and not any other "parent" you might have branched from when creating a topic branch), and a reasonable non-intrusive, non-misleading way to on-ramp into it.
