Re: [PATCH v4] merge: new autosetupmerge option 'simple' for matching branches

[Junio C Hamano <gitster@pobox.com>]

Tao Klerks <tao@klerks.biz> 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

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.

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.

> 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).  

The thing is, "simple" is *NOT* meant for triangular workflow.  It
was to cater to novice users who are used to cvs/svn style
centralized "there is one place everybody pulls from and pushes to,
which is where they meet" model.
> Based on your feedback here, maybe "simple" is not the right name to
> associate with workflow, its assumptions and tradeoffs - I believe is
> accurately represents the intent and closely relates to the apparent
> design intent behind the push.default=simple option, but I'd love
> proposals as to how to name (and do) it better!
>
>> Currently, with both set to "simple", you do not even get .remote
>> and .merge for the "topic" branch, so your "git pull" simply does
>> not work.  And "git push" will also refuse to work.
>>
>
> That's right - because the assumption is that you've just created a
> new independent branch - independent by name, and therefore
> independent by default. You can of course add "--track" if you know
> what you're doing and know this is a local-only branch and you want it
> to track what you branched from and have "pull" bring in changes from
> there (without explicitly specifying so)!
>
>> But then why are you [*] forking from origin/main in the first
>> place?  What is the purpose you created 'topic' and what do you
>> plan to do with the result you develop on 'topic'?
>
> The assumption, in this workflow, is that you plan to work on that
> branch, potentially push to origin to back up or share your work, and
> will decide explicitly when to merge in changes from the origin you
> branched (forked) from, or merge changes up there.
>
>>
>>         Side note: "you" do not refer to"Tao, the advocate of the
>>         'simple' configuration", but figuratively the user who
>>         followed the "simple" route and created topic out of
>>         origin/main that is not connected to origin/main.
>>
>> Whatever you commit on topic eventually becomes part of what you'd
>> push to origin or elsewhere.  I'd assume it would be origin, because
>> as the user who choose 'simple', you have some branches that you
>> push back to the same name over there.  Presumably, those are the
>> primary integration branches the project has, like 'trunk', 'main',
>> 'master', etc.
>>
>> So perhaps the user would have been better off to fork off of the
>> LOCAL branch that would eventually be pushed back?  In other words,
>> the above user who created 'topic' would have done
>>
>>     $ git checkout -b main origin/main
>>
>
> (completely beside the point, but they would be more likely to have
> just done "git checkout main", for the same outcome)
>
>> to use as a local integration branch that collects the work you will
>> do locally that is targetted for their 'main' track, so to create a
>> topic that aims to be part of what is pushed back to their 'main'
>> track, you would want to do
>>
>>     $ git checkout -b topic main
>>
>> instead?  That way, "git push" would either not get .merge/.remote
>> (when branch.autosetupmerge is set to 'true') or point at your local
>> 'main' branch.
>
> I'm not sure I understand or agree with what you're saying here with
> "would [otherwise] point at your local 'main' branch". I have to
> assume you mean that would be the outcome with "always",

Yeah, I meant to add the matching (when ... is set to ...) after the
sentence and forgot.  You inferred what I meant to say correctly.

> 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.

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.