On Fri, Feb 25, 2022 at 9:15 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "Tao Klerks via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > This commit introduces a new option to the branch.autosetupmerge > > setting, "simple", which is intended to be consistent with and > > complementary to the push.default "simple" option. > > Documentation/SubmittingPatches. > > We do not say "This commit does this". Instead, we say "Add a new > option that does X". Usually that is done after the explanation of > the status quo is finished to make readers understand what the > problem the change is trying to solve is. So... Yep, sorry, thx! (fixed, reroll coming!) > > > The push.defaut option "simple" helps produce > > predictable/understandable behavior for beginners, where they don't > > accidentally push to the "wrong" branch in centralized workflows. If > > they create a local branch with a different name and then try to do a > > plain push, it will helpfully fail and explain why. > > ... this would be a better first paragraph to start the proposed log > message with. > > With push.default set to "simple", the users fork from a > local branch from a remote-tracking branch of the same name, > and are protected from a mistake to push to a wrong branch. > If they create a ... and explain why. > > > However, such users can often find themselves confused by the behavior > > of git after they first branch, and before they push. At that stage, > > Depending on how they "branch", they may or may not be confused. Be > more specific to illustrate what problem you are solving, e.g. > > ... after they create a new local branch from a > remote-tracking branch with a different name. > > > their upstream tracking branch is the original remote branch, and pull > > will be bringing in "upstream changes" - eg all changes to "main", in > > a typical project where that's where they branched from. > > OK. So "pull" tries to grab from the upstream (which is most likely > an integration branch with bland name like 'master', 'main' or > 'trunk'), while "push" does not allow the work on a branch (which is > named after the theme of the work and not a bland name suitable for > integration branches) to be pushed to the upstream. > > It may probably not be so clear why it is a problem to many readers, > I suspect. Isn't that what happens in a typical triangular workflow > to work with a project with a centralized repository? You fork from > the integration branch shared among project participants, you work on > your own branch, occasionally rebasing on top of the updated upstream, > and when you are done, try to push it out to the integration branch, > and that final leg needs to be explicit to make sure you won't push > out to a wrong branch (in this case, a new branch at the remote with > the same name as your local topic branch) by mistake? > > > On the other hand, once they push their new branch (dealing with the > > initial error, following instructions to push to the right name), > > subsequent "pull" calls will behave as expected, only bring in any > > changes to that new branch they pushed. > > Is that because the upstream for this local branch is updated? > The "following instructions..." part may want to clarify. > > It somehow feels that a better solution might be to suggest > updating the push.default to 'upstream' when it happens? I dunno. > > In any case, now we have explained what happens with today's code, > here is a good place to propose a solution. Do so in imperative, > e.g. > > Allow branch.autosetupmerge to take a new value, 'simple', which > sets the upstream of the new branch only when the local branch > being created has the same name as the remote-tracking branch it > was created out of. Otherwise the new local branch will not get > any tracking information and > > or something, perhaps? Thank you for taking the time to make sense of the rambling / largely incoherent message and helping me identify some context other reviewers will expect. I've rewritten the whole thing to try to address these concerns, but of course I may well have introduced a whole new set. If nothing else, it's become even more rambling. Is there a recommended limit to the length of a commit message?
