Ben Boeckel [off-list ref] writes:
The `branch.autoSetupMerge` works well for setting up tracking a local
branch, but there is no mechanism to automatically set up a remote
tracking situation.
This description is probably insufficient to explain what's missing,
probably because "set up a remote tracking situation" is a bit
fuzzy.
Without this patch, I can do this already:
$ git checkout -t -b topic origin/topic
And after the above, we have
[branch "topic"]
remote = origin
merge = refs/heads/topic
Of course, you can instead use a short-hand DWIM, e.g.
$ git checkout topic ;# assuming origin/topic exists
gives us the same thing. In either case, topic knows to integrate
with the 'topic' branch from remote 'origin' and push back there.
So instead of saying "there is no mechanism to ...", be a bit more
specific what you can and cannot do in this first paragraph.
Then we can describe the solution we'd propose in the second and
subsequent paragraphs.
Thanks.
+branch.defaultRemote::
+ When a new branch is created with 'git branch', 'git switch' or 'git
+ checkout', this value will be used to initialize the
+ "branch.<name>.remote" setting.
You mean without "-t"? I offhand do not think of a reason why this
is a good idea. How would one create local topic branches that you
plan to merge locally into your own larger topic branch to be shared
with others? Shouldn't there be an easy way to countermand the
setting by this configuration?
+branch.defaultPushRemote::
+ When a new branch is created with 'git branch', 'git switch' or 'git
+ checkout', this value will be used to initialize the
+ "branch.<name>.pushRemote" setting.
Ditto.
+branch.defaultMerge::
+ When a new branch is created with 'git branch', 'git switch' or 'git
+ checkout', this value will be used to initialize the
+ "branch.<name>.merge" setting.
So the expected use case is to fork multiple local branches, to
integrate with the same branch from the remote? I think we can
already do
$ git checkout -t -b xyzzy origin/master
$ git checkout -t -b frotz origin/master
and you can lose -t with branch.autosetupmerge setting. As the "git
branch" command needs to get the name of your branch (e.g. 'xyzzy'
or 'frotz') and which remote tracking branch you start from
(e.g. 'origin/master'), even with branch.{defaultRemote,defaultMerge}
configuration, you wouldn't lose that many keystrokes, I suspect.
Or do you plan to make
$ git branch xyzzy
a short-hand for
$ git branch -t xyzzy origin/master
when defaultRemote and defaultMerge are set to 'origin' and
'refs/heads/master'? It would be way too confusing to start the
new branch from origin/master in such a case, as everybody learned
that "git branch xyzzy" that does not say where the branch initially
points at uses HEAD.
On Wed, Jul 28, 2021 at 10:48:56 -0700, Junio C Hamano wrote:
Ben Boeckel [off-list ref] writes:
quoted
The `branch.autoSetupMerge` works well for setting up tracking a local
branch, but there is no mechanism to automatically set up a remote
tracking situation.
This description is probably insufficient to explain what's missing,
probably because "set up a remote tracking situation" is a bit
fuzzy.
Fair enough. I finally understood what was going on with "tracking" only
recently. Usually I would track the remote's branch of the same name,
but I found that "tracking" `origin/master` instead of `myfork/topic`
makes `fugitive` render the following:
- commits on my topic that aren't integrated (this makes it easy to
tell it to "amend this commit" using its keybinding;
- commits on `master` that aren't on my topic (so I can see if there's
anything relevant to rebase on top of); and
- diffs against my fork's branch (as last fetched) so that I can see
the status.
Maybe this is a tooling issue, but I saw this as a potential way to
avoid having to specify this information on every topic I create.
Without this patch, I can do this already:
$ git checkout -t -b topic origin/topic
I should note that the *vast* majority of my development is done using
the fork-based workflow. I have `remote.pushDefault` set to my fork and
I use `push.default = simple` (there are only a handful of repositories
where "my fork" is also `origin` and I have, on multiple occasions,
wanted to make forks even there).
My normal pattern is that I'm on the target branch already, so I have:
$ git checkout -b topic
which doesn't do any tracking. Just `-t` makes it track my *local*
`master` when I really want it to track `origin/master`. AFAIK, there's
no shortcut for this other than to give the full `-t origin/master` at
branch creation time (and as something I do all the time).
And after the above, we have
[branch "topic"]
remote = origin
merge = refs/heads/topic
Of course, you can instead use a short-hand DWIM, e.g.
$ git checkout topic ;# assuming origin/topic exists
gives us the same thing. In either case, topic knows to integrate
with the 'topic' branch from remote 'origin' and push back there.
This doesn't match with my usual experience in fork-based workflows. I
want the topic to track `master` and then my `remote.pushDefault` makes
sure it goes to "the right place" when pushing.
So instead of saying "there is no mechanism to ...", be a bit more
specific what you can and cannot do in this first paragraph.
Then we can describe the solution we'd propose in the second and
subsequent paragraphs.
Thanks.
I'll work on an improved cover letter to give more background.
quoted
+branch.defaultRemote::
+ When a new branch is created with 'git branch', 'git switch' or 'git
+ checkout', this value will be used to initialize the
+ "branch.<name>.remote" setting.
You mean without "-t"? I offhand do not think of a reason why this
is a good idea. How would one create local topic branches that you
plan to merge locally into your own larger topic branch to be shared
with others? Shouldn't there be an easy way to countermand the
setting by this configuration?
Everything goes through merge requests for the projects I work on
day-to-day (even contributions to "my own" projects due to CI
workflows). I added a test that `--no-track` works for this case (which
given its rarity for me is the right tradeoff at least).
quoted
+branch.defaultPushRemote::
+ When a new branch is created with 'git branch', 'git switch' or 'git
+ checkout', this value will be used to initialize the
+ "branch.<name>.pushRemote" setting.
Ditto.
quoted
+branch.defaultMerge::
+ When a new branch is created with 'git branch', 'git switch' or 'git
+ checkout', this value will be used to initialize the
+ "branch.<name>.merge" setting.
So the expected use case is to fork multiple local branches, to
integrate with the same branch from the remote? I think we can
already do
$ git checkout -t -b xyzzy origin/master
$ git checkout -t -b frotz origin/master
and you can lose -t with branch.autosetupmerge setting. As the "git
branch" command needs to get the name of your branch (e.g. 'xyzzy'
or 'frotz') and which remote tracking branch you start from
(e.g. 'origin/master'), even with branch.{defaultRemote,defaultMerge}
configuration, you wouldn't lose that many keystrokes, I suspect.
There are times that I want to branch from HEAD, but track `master` (for
example, a branch destined for backporting to an older branch). The
equivalent of:
$ git checkout release
$ git checkout -b backported-branch
$ git branch --set-upstream-to=origin/master
Or do you plan to make
$ git branch xyzzy
a short-hand for
$ git branch -t xyzzy origin/master
when defaultRemote and defaultMerge are set to 'origin' and
'refs/heads/master'? It would be way too confusing to start the
new branch from origin/master in such a case, as everybody learned
that "git branch xyzzy" that does not say where the branch initially
points at uses HEAD.
No, it would just *track* `origin/master`, not branch from it. It should
be shorthand for:
$ git branch xyzzy
$ git branch --set-upstream-to=origin/master xyzzy
Though I personally use `git checkout -b` far more often to create
branches. And since "every" branch I make would have `-t origin/master`,
I wanted to have configuration to do this part for me.
Hopefully this gives a clearer picture of where I'm coming from.
Thanks,
--Ben