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). 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". 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? > [...] > -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? 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?
