Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: custom parameters #3

Open
zerodogg opened this issue May 4, 2016 · 6 comments
Open

Feature request: custom parameters #3

zerodogg opened this issue May 4, 2016 · 6 comments

Comments

@zerodogg
Copy link

zerodogg commented May 4, 2016

Being able to configure the remote to supply custom parameters, ie. for bandwidth limiting, would be useful. Perhaps stored in the git config like with rsync special remotes (annex-rsync-upload-options), ie. remote.annex-rclone-upload-options or similar. Right now I have achieved it by just editing the shell script itself, but a builtin/supported way of achieving the same would be a much nicer solution.

@DanielDent
Copy link
Member

@zerodogg Thanks for your feedback. I agree with you - I have been using the same solution you have as a stopgap measure, but it's an ugly hack.

I'd been thinking it might be nice to have something which could be set at run-time during a push as a command line option or an environment variable. But I definitely see the merits of having a configurable default. I also think repos should have the ability to set their own defaults (e.g. different machines with different network speeds) - a git config entry seems more appropriate than a setting for the remote itself.

@joeyh - I would appreciate your thoughts. Looking over the special remote protocol documentation page on the wiki, it's unclear to me if git-annex has support for what I'm looking to do. Any suggestions would be appreciated.

@joeyh
Copy link

joeyh commented May 6, 2016

You can use GETCONFIG to implement this. Configs are stored in annex:remote.log so will be persistent.

@DanielDent
Copy link
Member

Wouldn't the values of GETCONFIG/SETCONFIG would be shared by all copies of the repo? Or have I misunderstood. A machine on a high performance connection will want a different setting than a machine on a lower performance connection.

@joeyh
Copy link

joeyh commented May 6, 2016

Daniel Dent wrote:

Wouldn't the values of GETCONFIG/SETCONFIG would be shared by all copies of the
repo? Or have I misunderstood. A machine on a high performance connection will
want a different setting than a machine on a lower performance connection.

They are shared amoung clones of the repo, yes.

So, you can use GETCONFIG to get global defaults, and override those
with git config settings.

see shy jo

@DanielDent
Copy link
Member

Is there a supported way for a remote to access the git config settings? I don't see a command in the protocol that would provide for that. Are remotes guaranteed to have an environment (PWD) such that opening ".git/config" will work?

@joeyh
Copy link

joeyh commented May 6, 2016

Daniel Dent wrote:

Is there a supported way for a remote to access the git config settings? I
don't see a command in the protocol that would provide for that. Are remotes
guaranteed to have an environment (PWD) such that opening ".git/config" will
work?

Oh, good question. You want to use git config to pull values of of the
git config files, don't read them yourself.

There are a couple of ways that git-annex can be run that make it use a
non-standard .git directory location. At least some of those won't be
visible to the external special remote. I think that neither of these
currently are:

git --git-dir=/whatever annex
GIT_DIR=/whatever git annex

git-annex could fix this by propigating GIT_DIR on to the external special
remote.

Also, if you have a config foo.bar, and the user wants to temporarily
override it, they might try:

git -c foo.bar=newval annex

And while git-annex would see such overridden configs, they don't get passed
through to the external special remote. I'd need to add something to the
special remote protocol to support this, but maybe it's enough of an
edge case to not be worth complicating the protocol with it.

see shy jo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants