On 2021.10.18 20:31, Ævar Arnfjörð Bjarmason wrote: > > On Sat, Oct 16 2021, Josh Steadmon wrote: > > > 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@xxxxxxxxxx/ > > [...] > > -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.
