Allow storing configuration in git config #29

New Issue

strk · 2019-05-26T14:52:26Z

strk commented

2019-05-26 14:52:26 +00:00

So that you can use different instances of Gitea for different git repositories.

lunny commented

2019-05-26 15:08:52 +00:00

It has been implemented.

strk commented

2019-05-26 15:31:53 +00:00

Uhm, then why the README says to do the login with an url first ? It's not very clear how it works (but feel free to close if done already, great work!)

Uhm, then why the README says to do the `login` with an `url` first ? It's not very clear how it works (but feel free to close if done already, great work!)

lunny added the

kind

question

label 2019-06-09 13:37:46 +00:00

root360-AndreasUlm commented

2019-07-15 05:46:19 +00:00

@strk Can please describe the wanted behaviour in more detail?

Tea connects and leverages the API of Gitea and to do that is bound to use API tokens for authentication.

The git config (e.g. ~/.gitconfig) does only contain information to manage the git repositories using the git protocol via HTTP(S) or SSH. This protocol is not and cannot be used by Tea as Gitea does not provide the management features via this protocol.

If we would store the connect configuration in the git config we also might break git as AFAIK git does not provide a dedicated thrird-party space which other commands might use.

If I did understand your feature request right, why should we store the connection information only we need in the git config?

@strk Can please describe the wanted behaviour in more detail? Tea connects and leverages the API of Gitea and to do that is bound to use API tokens for authentication. The git config (e.g. ~/.gitconfig) does only contain information to manage the git repositories using the git protocol via HTTP(S) or SSH. This protocol is not and cannot be used by Tea as Gitea does not provide the management features via this protocol. If we would store the connect configuration in the git config we also might break git as AFAIK git does not provide a dedicated thrird-party space which other commands might use. If I did understand your feature request right, why should we store the connection information only we need in the git config?

lunny commented

2019-07-15 06:12:48 +00:00

@strk did you mean store the configurations in git's config. i.e. /config ?

@strk did you mean store the configurations in git's config. i.e. <reporoot>/config ?

strk commented

2019-07-15 07:33:25 +00:00

It is not true that ~/.git/config only contains information useful for git protocol. I'm not aware of official "third-party space" within that config file but I know a few tools that do make their own space. Examples:

Distributed bug tracking (https://lwn.net/Articles/434922/)
Uses an [sd] section
git-svn uses an [svn] section
GitLab commandline tool uses a [gitlab "api"] section

The GitLab one is the closer to what we want. It looks like this:

[gitlab "api"]
        endpoint = https://gitlab.com/api/v4

If we can avoid custom blocks that's also great, but the goal is to make it easy to allow users to just tea <dothis> and tea <dothat> with those operations taking place in the appropriate Gitea deploy without having to specify it on every call, thus storing a "contextual" configuration on a per-repository basis. Moving the git repository around your filesystem should not (imho) require you to re-configure "tea", thus the idea of re-using .git/config file, as other similar tools do.

It is not true that ~/.git/config only contains information useful for git protocol. I'm not aware of official "third-party space" within that config file but I know a few tools that do make their own space. Examples: - Distributed bug tracking (https://lwn.net/Articles/434922/) Uses an `[sd]` section - git-svn uses an `[svn]` section - GitLab commandline tool uses a `[gitlab "api"]` section The GitLab one is the closer to what we want. It looks like this: ``` [gitlab "api"] endpoint = https://gitlab.com/api/v4 ``` If we can avoid custom blocks that's also great, but the goal is to make it easy to allow users to just `tea <dothis>` and `tea <dothat>` with those operations taking place in the appropriate Gitea deploy without having to specify it on every call, thus storing a "contextual" configuration on a per-repository basis. Moving the git repository around your filesystem should not (imho) require you to re-configure "tea", thus the idea of re-using `.git/config` file, as other similar tools do.

root360-AndreasUlm commented

2019-07-15 09:16:37 +00:00

@strk Thanks for the clarification of your use-case. As @lunny already wrote this use-case is already implemented in tea but not via writing an own configuration. The tea config file is only used to store the API access information for all known Gitea servers. The repository to work on can be defined in two ways, either use --repo <repo-name> which allows you to run the tea command everywhere in your filesystem or you cd into the repository path and run tea. When tea detects that it is running within a valid git repository path it sets the repository directly without requiring --repo.

If you found a situation where this auto-detection does not work, please share it with us so we can fix any possible issue.

@strk Thanks for the clarification of your use-case. As @lunny already wrote this use-case is already implemented in tea but not via writing an own configuration. The tea config file is only used to store the API access information for all known Gitea servers. The repository to work on can be defined in two ways, either use `--repo <repo-name>` which allows you to run the tea command everywhere in your filesystem or you cd into the repository path and run tea. When tea detects that it is running within a valid git repository path it sets the repository directly without requiring `--repo`. If you found a situation where this auto-detection does not work, please share it with us so we can fix any possible issue.

strk commented

2019-07-15 09:43:21 +00:00

How does tea determines which API to hit when called from within a git repository without the --repo switch ? I'm thinking of a situation in which you have multiple remotes registered in your repository...

How does `tea` determines which API to hit when called from within a git repository without the `--repo` switch ? I'm thinking of a situation in which you have multiple remotes registered in your repository...

root360-AndreasUlm commented

2019-07-15 11:03:24 +00:00

In https://gitea.com/gitea/tea/src/branch/master/cmd/config.go#L189 it determines all configured remote URLs and compares them with the configured API endpoints. As soon as one matches this is used for the communication.

This has a corner-case when you have several remotes which have Gitea endpoints. In that case always the first matching endpoint is used. The cli parameter --repo always supercedes this determination logic thus in that case you still can control the endpoint by using the parameter.

In https://gitea.com/gitea/tea/src/branch/master/cmd/config.go#L189 it determines all configured remote URLs and compares them with the configured API endpoints. As soon as one matches this is used for the communication. This has a corner-case when you have several remotes which have Gitea endpoints. In that case always the first matching endpoint is used. The cli parameter `--repo` always supercedes this determination logic thus in that case you still can control the endpoint by using the parameter.

strk commented

2019-07-15 11:14:16 +00:00

I think the corner-case is enough to prefer an encoded per-repo configuration.
At least the CLI should prompt user in case of multiple matches, for now.
And the prompt message/warning could recommend a way to locally-encode configuration (tea login could write into .git/config, maybe in a [gitea] section...

I think the corner-case is enough to prefer an encoded per-repo configuration. At least the CLI should prompt user in case of multiple matches, for now. And the prompt message/warning could recommend a way to locally-encode configuration (`tea login` could write into `.git/config`, maybe in a `[gitea]` section...

root360-AndreasUlm commented

2019-07-15 13:16:11 +00:00

To get on the same page and clear possible confusions I created with my earlier post I'll shortly describe the parameters login and repo.

--login <login-alias>: defines the login information stored in ~/.tea/tea.yml that should be used to connect to the Gitea API of a server. If the tea-command is run within a git-repository path with an remote.origin.url matching any url or ssh_host stored in ~/.tea/tea.yml this parameter can be omitted as the matching login information will be used.

--repo <repo-name>: defines the repository that should be contacted on the Gitea API for given subcommand (e.g. pulls). If the tea-command is run within a git-repository path the parameter can be omitted as the repo-name is extracted from remote.origin.url.

Those information are based on the code of tea and partly contradict my previous explanations as I was mixing up both parameters.

Concerning storing login information in .git/config that's IMHO a bad idea because that means that a user has to configure his login information in every git respository instead of once for each Gitea server. IMHO that is unusable (e.g. for my 145 repositories on one Gitea server).

To get on the same page and clear possible confusions I created with my earlier post I'll shortly describe the parameters login and repo. `--login <login-alias>`: defines the login information stored in ~/.tea/tea.yml that should be used to connect to the Gitea API of a server. If the tea-command is run within a git-repository path with an `remote.origin.url` matching any `url` or `ssh_host` stored in ~/.tea/tea.yml this parameter can be omitted as the matching login information will be used. `--repo <repo-name>`: defines the repository that should be contacted on the Gitea API for given subcommand (e.g. pulls). If the tea-command is run within a git-repository path the parameter can be omitted as the repo-name is extracted from `remote.origin.url`. Those information are based on the code of tea and partly contradict my previous explanations as I was mixing up both parameters. Concerning storing login information in `.git/config` that's IMHO a bad idea because that means that a user has to configure his login information in every git respository instead of once for each Gitea server. IMHO that is unusable (e.g. for my 145 repositories on one Gitea server).

🎉 1

strk commented

2019-11-11 11:14:46 +00:00

Concerning storing login information in .git/config that’s IMHO a bad idea because that means that a user has to configure his login information in every git respository instead of once for each Gitea server.

Git config is also read from ~/.gitconfig. I just went looking and indeed I found an [hub] section in there, which is where the hub commandline tool for github API interaction stores its configuration.

Putting config in the broather git config allows you to put it in per-repo or per-user, or tweak via other means, but it's definitely something used my different tools (gitlab cli, github cli, distributed bug tracker, other git plugins...) and users already have tools to manage those configurations

> Concerning storing login information in .git/config that’s IMHO a bad idea because that means that a user has to configure his login information in every git respository instead of once for each Gitea server. Git config is also read from `~/.gitconfig`. I just went looking and indeed I found an `[hub]` section in there, which is where the `hub` commandline tool for `github` API interaction stores its configuration. Putting config in the broather git config allows you to put it in per-repo or per-user, or tweak via other means, but it's definitely something used my different tools (gitlab cli, github cli, distributed bug tracker, other git plugins...) and users already have tools to manage those configurations

lunny commented

2019-11-11 15:19:27 +00:00

@strk What's wrong to store them in ~/.tea/ ?

strk commented

2019-11-12 08:51:38 +00:00

Nothing wrong in ~/.tea but is's a nice feature to be able to rename a repository directory and still retain configuration specific for it, as well as sharing the configuration across multiple worktrees of the same git repo. Both the above characteristics are available when using git-config.

lunny commented

2019-11-12 14:53:31 +00:00

@strk hm, It seems storing it to .git/config is a good idea for those who like moving repositories here or there frequently.

@strk hm, It seems storing it to `.git/config` is a good idea for those who like moving repositories here or there frequently.

👍 1

noerw commented

2020-09-30 08:33:22 +00:00

While an interesting idea to use git-config, it seems unreasonable to support another config format.

The moving-your-repo-on-local-disk-around problem as described does not exist, tea will always use the same config file anyways.

If you need to hardcode a specific login for your repo, i suggest you use a git alias, and use tea via git tea <subcommand>

git config alias.tea '!tea -l <your-login-id>'

Closing this, feel free to come back to this.

While an interesting idea to use git-config, it seems unreasonable to support another config format. The moving-your-repo-on-local-disk-around problem as described does not exist, `tea` will always use the same config file anyways. If you need to hardcode a specific login for your repo, i suggest you use a git alias, and use tea via `git tea <subcommand>` ```sh git config alias.tea '!tea -l <your-login-id>' ``` Closing this, feel free to come back to this.

👍 1

noerw closed this issue

2020-09-30 08:33:22 +00:00

Sign in to join this conversation.

No Milestone

No Assignees

4 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/tea#29