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

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

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.

None of the above, I guess.