Tao Klerks <tao@xxxxxxxxxx> writes:
>> 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.
"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").
This depends on what you are really trying to achieve. If we think
it through, perhaps it may turn out to be a combination of a bit
flawed workflow with a bit inadequate toolset.
With "simple" (both in branch.autosetupmerge and push.default), I
can see that if you create "main" from their "main" and "maint" from
their "maint", you want to see that
(1) your "git pull" to integrate what happend on their "main" or
"maint" respectively, and
(2) your "git push" to push what you did on your "main" to their
"main", and "maint" to "maint".
But it is totally unclear what you really want to do on "topic" you
created this way:
$ git checkout -b topic origin/main
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.
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'?
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
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.
- The symptom you get from the former is no better than what you
get from branch.autosetupmerge=simple but it is not worse.
"push" and "pull" refuses to work and suggest you to do something
additional.
- The latter would make your "git push" and "git pull" on 'topic'
to work with your local 'main', treating your 'main' in a way
very similar to how you treat your remote 'main' when you are on
your own 'main', which is quite reasonable if your change flow is
designed to be "work on topic, when the changes on topic proves
OK, send that to main, and when the changes on main proves OK,
send that to their main".
I guess I am esseentially saying that the usefulness of "simple" for
branch.autosetupmerge is dubious.
> 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?)
None of the above, I guess.
