Re: [PATCH v3] branch: add flags and config to inherit tracking

On 2021.10.18 20:31, Ævar Arnfjörð Bjarmason wrote:

On Sat, Oct 16 2021, Josh Steadmon wrote:

quoted

It can be helpful when creating a new branch to use the existing
tracking configuration from the branch point. However, there is
currently not a method to automatically do so.

There's no method to get *only* that config, but this use-case is why
the "-c" option (copy branch) was added.

I haven't looked at this in any detail, but the seeming lack of mention
of it in the commit message & docs makes me wonder if you missed that
that option could do what you wanted (but granted, it does a lot more,
which maybe you don't want).

Indeed, I did miss that option. Thank you for the pointer. I am
conflicted about whether or not we want to copy all the branch
configuration. Most of the options do seem useful to copy, but the
existing config values available for `branch.autoSetupMerge` are
strictly about setting up `branch.<name>.remote`, `branch.<name>.merge`,
and `branch.<name>.rebase`. Adding a new value here that additionally
pulls in all the rest of the config may be confusing. Alternatively we
could add an entirely new option, but then its interaction with
`branch.autoSetupMerge` would be confusing as well.

But in terms of implementation can't this share more code with the copy
mode? I.e. I'd think that this would just be a limited mode of that,
where we pass some whitelist of specific config to copy over, instead
the current "all the config" with "copy".

I will look into the copy machinery and see what can be reused in V4.

And should these options be made to work together somehow? I.e. if you
want to copy branch A to B, but copy tracking info from C?

I am skeptical of the benefit here, but I'm certainly willing to hear
arguments in favor.

The motivation for this series is for Git users (who are not necessarily
Git experts) to have a simple config they can tune to make reduce
friction for the use case of having large repositories with many
submodules (see Emily's discussion [1]). The idea is that we have many
people with a workflow where they'd have `submodule.recurse=true` and
`branch.autoSetupMerge=inherit`. When they checkout a new branch in the
superproject, branches would also be checked out in the submodules, and
appropriate tracking information would also be inherited so that they
can later `git push` without having to manually configure tracking for
every submodule.

This would be a very common operation for these users, and should
therefore require as little friction as possible. While I can see use
cases for your "copy A to B but copy tracking from C", it seems to me
that this would be a much less common situation, and is probably going
to be needed by Git experts who are capable of setting this manually
without relying on configs to make it the default behavior.


[1]: https://lore.kernel.org/git/YHofmWcIAidkvJiD@google.com/ (local)

quoted

[...]
 -t::
---track::
+--track [inherit|direct]::
 	When creating a new branch, set up `branch.<name>.remote` and
-	`branch.<name>.merge` configuration entries to mark the
-	start-point branch as "upstream" from the new branch. This
+	`branch.<name>.merge` configuration entries to set "upstream" tracking
+	configuration for the new branch. This

Setting up ".remote" is what --tracke does, but doesn't it make sense
for such an option to copy over any other config related to that area,
e.g. also .pushRemote, as a user may have edited it since the creation
of the copied-from branch?

Yes, .pushRemote and .mergeOptions both seem like they'd be useful to
copy here.

Maybe, maybe not. But this & the above comparison with copy makes me
wonder if we'd be better off with some mode similar to the matching
regexes "git config", i.e. you could do a "copy" but only on a list of
matching variables.

Then the --track mode could just be implemented in terms of that, no?

Using config matching to only copy portions of the branch config seems
overkill to me. IMO it would be better to get agreement for which of the
branch.<name>.* variables to copy, and then use that consistently for
all possible settings of `branch.autoSetupMerge` and
`branch.autoSetupRebase`. If that allows us to reuse the existing copy
machinery, then so much the better.