Re: [PATCH v2 1/2] merge: new autosetupmerge option 'simple' for matching branches

[Tao Klerks <tao@klerks.biz>]

On Fri, Feb 25, 2022 at 9:15 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Tao Klerks via GitGitGadget" <gitgitgadget@gmail.com> 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?