Closed cap10morgan closed 4 years ago
Also had a thought on this over the weekend, but needs discussion and certainly can be a future improvement:
What if we stored the team membership in files in the repo, then on push to the HEAD branch (still needs implemented) we updated the tupelo authentications array? Then any future branch-limiting conditions, such as master can only be updated after # thumbs on a PR, will benefit from that protection.
A few questions / comments, but lgtm 👍
It seems the key migration is handled automatically? Are there any other effects or manual steps for existing users?
Yes it should be. The other effect is that if the user sets a dgit username that is different than what's in their ~/.gitconfig
file, it will be written to the local repo's ./.git/config
file.
Implements #31.
Adds new
team (add | list | remove)
andwhoami
commands. Asks for username on init and stores it in git config. A global default username can be configured withgit config --global dgit.username [username]
, but it also looks for any configured GitHub username and suggests that for your dgit username. It then suggestsusername/basedir
for the full repo name.It can also migrate the old
dgit.default
keyring entries to the newdgit.[username]
entries.And a few other small fixes & improvements (which I will pull into their own PR if controversial).
Tests shmests... ;)