review state of configuration

[charlierudolph]

Currently here are all the configuration values we are storing in the git config:

• git-town.main-branch-name
• git-town.perennial-branch-names
• git-town..parent
• git-town.code-hosting-driver
• git-town.code-hosting-origin-hostname
• git-town.github-token
• git-town.pull-branch-strategy
• git-town.offline
• git-town.new-branch-push-flag
• git-town.sync-upstream
• git-town.ship-delete-remote-branch (in PR)

Notes:

• Some of these are documented on our README and others are only documented for specific commands.
• We have commands for interacting with some of them and others we require users to run a git config command to update
• The git-town config command also currently only prints a subset of these.

I think at the very least we should update the config command to print everything and otherwise think it would be nice to have more subcommands under git town config for interaction with all of these.

[kevgo]

I agree on both! Here is an idea for setting the config values. When running git town config setup, the user sees a "main menu" that show a list of all config settings with their current value.

? Please select a configuration item to change  [Use arrows to move, enter to select, type to filter]
> main development branch: 
  perennial branches: 
  push new branches: no
  pull-branch-strategy: merge
  offline: no
  github-token:
  sync-upstream: no
  code-hosting-driver: 
  code-hosting-origin-hostname:
  ship-delete-remote-branch: yes

The user can move the caret up and down to select a config setting. When pressing ENTER, the user sees UI to change this setting. For example, when selecting offline, the UI looks like this:

? Please select a new value for the offline setting
> disabled
  enabled for this repo
  enabled for all repos on this computer

This results in changing this setting in the local or global Git configuration.

[blaggacao]

There is a bit of a mixed design for the code-hosting configuration:

• (code-hosting-)github-token: is github namespaced
• code-hosting-driver: is not
• code-hosting-origin-hostname: is not

To make this straight and propper, those should be namespaced by the remote name, so potentially via slightly different implementation of GIT_TOWN_REMOTE, we can have easy peasy per origin configuration, and when we want to swap origin for upstream, we can gradually span git-town into forking PR support. #686 #928 #336

[kevgo]

@blaggacao great idea! This would be a solid foundation for supporting additional remotes, for example what #1181 is talking about.

[kevgo]

To make the ideas in this ticket actionable, I have extracted #1951 andn #1952.