Bug 337820

Comment 1 Tomasz Zarna 2011-03-03 07:19:36 EST

I can imagine an API that looks like this:

"git config --global [--get] {key}" > GET /git/config/{key}
"git config --global --get-all" > GET /git/config/
"git config --global {key} {value}" > PUT /git/config/{key}, {value} in body
"git config --global --unset {key}" > DELETE /git/config/{key}

Configurting repositories could be done analogically:

"git config {key}" > GET /git/config/clone/{id}/{key}
...

Comment 2 Szymon Brandys 2011-03-07 11:18:28 EST

So far we will be configuring clones based on the Orion user profile. When the git repos navigator is done, we will be able to configure them directly.

Comment 3 Tomasz Zarna 2011-03-07 12:10:36 EST

Added a simple test - e4252aa81bc8a4fcec50ef6b12516d0f91195371. Fails at the moment.

Comment 4 Piotr Janik 2011-06-01 06:04:48 EDT

I'm planning to work at this task.
Part of API regarding global options seems good for me. However, part which is connected with the given repository has a different structure from i.e. API of git branch/remote which I'm familiar with.
What about something like this:
"git config {key}" > GET /git/config/{key}/file/{id} ?
So, instead of 'clone/{id}' segment, rather 'file/{id}' at the end of URI. It will be more more consistent with APIs connected with git repositories.

Comment 5 Tomasz Zarna 2011-06-01 06:51:55 EDT

(In reply to comment #4)
> So, instead of 'clone/{id}' segment, rather 'file/{id}' at the end of URI. It
> will be more more consistent with APIs connected with git repositories.

I would use a longer form : /git/config/{pref.key}/clone/file/{path}. This way we leave no doubt that the /file part identifies a clone. Obviously, the {path} should point to a clone, not a folder in a repository or a parent folder.

Comment 6 Piotr Janik 2011-06-03 06:42:45 EDT

First version of my proposition: https://github.com/pjanik/orion.server/commit/74669af592a87c89bc8146236c728c5d806cb036
Changes contains REST API for configuring single repository (list configuration variables, set, modify and delete a single variable) and proper tests. I wrote all this code and have the rights to contribute it to Eclipse under the eclipse.org web site terms of use. 

I can see problems connected with global config. In fact, there is no global configuration file for user in Orion. When there is a need to get some variable from global config (i.e. some variable doesn't exist in local one), JGit by default uses base configuration file - most frequent it will be ~/.gitconfig file, which is common for all Orion users on the given server. So, two problems:
1. During listing configuration for repository (config --local --list => GET /gitapi/config/clone/file/a), we can see some variables, which aren't from local config, but i.e. from ~/.gitconfig. I think that shouldn't happen. JGit always uses some base configuration file as a fallback and I don't know how to disable such behaviour. I've tried to look into JGit source code and it seems to be hardcoded. Bug?
2. How to manage global configuration for a user? My idea is to keep all "global" variables in the user profile or its dedicated part. During each clone or init operation, all these variables will be set in the repository local configuration file. So, it's similar to what we do now with user.name and user.email, but extended to any variable.

Comment 7 Szymon Brandys 2011-06-07 13:11:14 EDT

1. I would implement PUT to modify config entries. Should be easy, since you have POST already implemented.

2. There is a not used baseLocation variable in #handleDelete.

(In reply to comment #6)
> 1. During listing configuration for repository (config --local --list => GET
> /gitapi/config/clone/file/a), we can see some variables, which aren't from
> local config, but i.e. from ~/.gitconfig. I think that shouldn't happen. JGit
> always uses some base configuration file as a fallback and I don't know how to
> disable such behaviour. I've tried to look into JGit source code and it seems
> to be hardcoded. Bug?

I would expect to see the same variables that I see in the Git console. If the list is different it is a bug, either in our code or in JGit and should be fixed.

> 2. How to manage global configuration for a user? My idea is to keep all
> "global" variables in the user profile or its dedicated part. During each clone
> or init operation, all these variables will be set in the repository local
> configuration file. So, it's similar to what we do now with user.name and
> user.email, but extended to any variable.

I would just set repo variables for the user and the mail at this point as we do already.

I would also raise a separate bug for the global configuration. Most likely we would need support from JGit. I can think about some kind of configuration providers which could be set similarly to credential providers.

Comment 8 Piotr Janik 2011-06-08 07:03:19 EDT

(In reply to comment #7)
> 1. I would implement PUT to modify config entries. Should be easy, since you
> have POST already implemented.
Done. 
> 2. There is a not used baseLocation variable in #handleDelete.
Fixed.

> I would expect to see the same variables that I see in the Git console. If the
> list is different it is a bug, either in our code or in JGit and should be
> fixed.
Ok, now we have something similar to "effective configuration" displayed by EGit. I will leave it as it is and open a bug for JGit with with my problem connected with local repo.
 
> I would just set repo variables for the user and the mail at this point as we
> do already.
> 
> I would also raise a separate bug for the global configuration. Most likely we
> would need support from JGit. I can think about some kind of configuration
> providers which could be set similarly to credential providers.
Ok.

New version with tests updated:
https://github.com/pjanik/orion.server/tree/bug337820

Comment 9 Szymon Brandys 2011-06-08 10:09:14 EDT

Fixed with 6ce52f26c2b808e528b04987878259a183d3e45e.