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

Is there a way to use command line switches instead of options ( config ) file? #13

Open
gansbrest opened this issue Aug 25, 2014 · 6 comments

Comments

@gansbrest
Copy link

In our setup with multiple developers we can't commit .realsync file to the repo, because it contains environment data which could be unique for every developer. We also don't want developer to answer all of those initial questions, because our setup is kind of complicated ( docker with VM on Mac or Windows where developer not always understands all the details and we want to hide some complexity ).

One option we have at the moment is to generate .realsync file dynamically, but in my mind it would be easier to just pass command line options to the realsync binary. Is there a way to do this or config file is the only option at the moment?

@dimikot
Copy link
Owner

dimikot commented Aug 25, 2014

At the moment, the config file is the only option. But it supports loading of other configs:

load = some_file

So you may commit a part of the file to the repo and generate the other part only. You may also generate .realsync file somewhere in a temp directory and run

realsync path_to_this_temp_dir

@gansbrest
Copy link
Author

I see, thanks for you advice. I was under impression that realsync expects first attribute to be "dir to synchronize", not path to the .realsync config? It would be great if I could specify a path to the config file only with some kind of command line switch.

In normal scenario we assume developer will do git pull of the repo, and will execute some startup script ./d start where that d script would pregenerate .realsync config and will do some other "magic". If I understood correctly you recommend to create another copy of the repo just to avoid placing .realsync file into the "main" repo? But then you would have to keep "real" and "shadow" repo in sync with files changes.. Hmm..

@hempalex
Copy link

Dmitry, why not use a "." as a "local" in .realsync?

@gansbrest gansbrest reopened this Aug 25, 2014
@gansbrest
Copy link
Author

@hempalex What do you mean by "local"?

@hempalex
Copy link

I't a question to Dmitry about .reasync file - a "local" variable contain to absolute path to folder being synced. I'm looked in the source code and i think this question is stupid because my workflow is not the only one.

@filipecatraia
Copy link

Hey gansbrest, why not include a config-sample file in the repo, and have developers just fill in the blanks? They'd then save it as config, and that is included in your .gitignore.

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

4 participants