On Thu, Apr 21, 2022 at 3:53 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Tao Klerks <tao@xxxxxxxxxx> writes: > > > If they branched from a different-name remote branch (they created an > > new / independent local branch), then no remote tracking relationship > > will have been set up, and instead of the "fatal: The upstream branch > > of your current branch does not match > > the name of your current branch" error and advice, they will get a > > much simpler error and advice: > > > > --- > > fatal: The current branch whatevs has no upstream branch. > > To push the current branch and set the remote as upstream, use > > > > git push --set-upstream origin whatevs > > --- > > > > When they follow those instructions, they will be in the "simple" > > setup same as if they had just branched from same-name. > > Which means that they need to see an error once, offered to either > set push.default or branch.autosetupmerge (it is not "and/or", but > "or", because you want to tell them to set "instead of push.default, > set branch.autosetupmerge"), and if they follow the latter, they have > to then hit a different error and be told to do the "set-upstream" > individually. They don't *have* to hit that error, they can set --set-upstream pre-emptively, but if they're "just following prompts" then that's what happens, yes. > I am wondering if that is more irritating than it is > worth. Instead, if you tell them to use branch.autosetupmerge=simple > and use push.default to something better than simple, wouldn't that > cover more cases and give fewer roadblocks to the end-user with > unnecessary errors? I think you're on to something I missed here. Unfortunately, I'm not sure what "something better than simple" for push.default actually is, in the current system. The most obvious option is to set it to "current", so: - you only get branch-time tracking for same-name branches because of branch.autosetupmerge=simple, and - you always get same-name pushes regardless of whether there is an upstream or not thanks to push.default, so you never see a "do this other thing to push" message... But then you have a new problem: While new branches push consistently, they never have an upstream tracking ref! This in turn means these no-tracking-ref branches, although they push smoothly, do not show ahead/behind state in "git status", and simply don't support a regular "git pull". That's not "simple". Where I think you're onto something, is that I believe there *should* be a way to say "if I request a default push and there is *no* remote tracking branch, then just push to the first remote, using the same branch name, *and set up tracking*". Now that would be simple. I don't know whether that behavior would require yet another push.default value, or if there's a better way of integrating it into the existing options/behaviors. I'm also not sure what should happen, in this scheme, if I happened to clash/overlap with an existing remote tracking branch. But this does seem like where I would like to end up. > > >> Setting the latter to 'simple' > >> means there are *MORE* branches that do not have .remote/.merge set > >> up, doesn't it? Which in turn means that we are relying more on > >> what push.default is set to, right? > > > > No > > Why no? if setupauto is yes, then any new branch forked from a > remote-tracking branch will get .remote/.merge set up, and with these > specific configuration they can "push" back to the configured place. > If it is set to simple, only new branches forked from a remote-tracking > branch that happens to have the same name will get it, and others do > not get .remote/.merge set up. But as long as push.default is set to "simple", *which is the only way you get the above message ever*, those cases where the new setupauto option avoids a tracking branch altogether simply change the error message from "your remote branch name does not match - you have lots of options" to "you do not have a remote branch yet - push like this (and you'll be all set for this branch henceforth)". Insofar as you can only ever get the "you might want to set setupauto to simple" message when push.default is set to simple, the set of cases where you get an error on push ends up being the exact same set of cases - you just get a clearer more sensible error. > Which means user's "git push" will then > consult push.default settings, and setting it right becomes more > important, no? If there were another push.default option that led to more automatic *and* correct outcomes, I would agree - and I believe that pursuing the existence of such an option makes sense. Do you agree that none of the push.default options available today are "right" for this flow? Do you have a preference or opinion as to whether: * push.default=current should be changed to set up tracking when absent, or * push.default=simple should be changed to "simply" push and set up tracking when there is no tracking, or * a new push.default option should be introduced for this behavior, or * some other configuration should be introduced to specify "and set up tracking on default push if missing" (and if so, under what circumstances should it kick in?)
