Include database.sample.yml in new projects

[teamon]

For config files that can contain sensitive data put it in .gitignore, add sample file to repository and write about it in README. The file should be named using the following convention:

FILE_NAME.EXT -> FILE_NAME.sample.EXT, so database.yml becomes database.sample.yml. This is better than FILE_NAME.EXT.example because it keeps the file extension in place.

Files that should have samples:

• config/database.yml - obvious
• config/mongoid.yml - if using mongo...
• config/application.yml - for lovely cat
• config/settings.*.yml, config/settings/*.yml madness - rails_config you bustard

[jandudulski]

This is better than FILE_NAME.EXT.example because it keeps the file extension in place.

Makes sense.

Obvious :+1:

[bartoszrega]

:ok_hand:

[sheerun]

ok

[jandudulski]

:shipit:

[sheerun]

I chnaged my mind. We should include commented code in normal files (like database.yml) and add them to .gitignore

[teamon]

Why? I can't see any reason besides dealing with issues when something wants to parse commented file...

On Sunday, 4 August 2013, Adam Stankiewicz wrote:

I chnaged my mind. We should include commented code in normal files (like database.yml) and add them to .gitignore

— Reply to this email directly or view it on GitHubhttps://github.com/monterail/guidelines/issues/156#issuecomment-22071100 .

[sheerun]

I don't see reason not to. I don't know what you mean by issues with parsing commented file. Comments are part of yml and are parsed normally.

[teamon]

There might be other file formats than yml. And updating example file would be a pain (think about application.yml or even mongoid.yml which includes more options than just user/pass for db)

On Sunday, 4 August 2013, Adam Stankiewicz wrote:

I don't see reason not to. I don't know what you mean by issues with parsing commented file. Comments are part of yml and are parsed normally.

— Reply to this email directly or view it on GitHubhttps://github.com/monterail/guidelines/issues/156#issuecomment-22075240 .

[sheerun]

In your examples there are none. Ruby files can have comments too. I don't see a problem with updates. Even figaro adds commented application.yml and adds it to .gitignore.

[teamon]

If you want to update ignored file, first you have to reset it to the version from repository, then do changes, add with force, commit and then brig back your own changes that you don't want to commit to repository. Where is the advantage over *.sample file?

On Sunday, 4 August 2013, Adam Stankiewicz wrote:

In your examples there are none. Ruby files can have comments too. I don't see a problem with updates. Even figaro adds commented application.yml and adds it to .gitignore.

— Reply to this email directly or view it on GitHubhttps://github.com/monterail/guidelines/issues/156#issuecomment-22076339 .

[sheerun]

I'd do simple merge. In case of *.sample you have to diff file in your mind. Where is the advantage?

[sheerun]

Anyway we can go with sample files for now.

[teamon]

It is exactly the other way around. If you have file X in .gitignore and you have your local modifications in it, when you want to commit a change to that file to repo you have to discard all your local changes, made this on modification and then force add and commit. With X.sample file all you need to do is make a change to that file and do a simple regular commit. Mo merges, no conflicts, no tricks.

On Sunday, 4 August 2013, Adam Stankiewicz wrote:

Anyway we can go with sample files for now.

— Reply to this email directly or view it on GitHubhttps://github.com/monterail/guidelines/issues/156#issuecomment-22076541 .

[sheerun]

I understand what you mean

[sheerun]

I would argue about sample vs example. Imho latter is better (more canonical) although one letter longer.. And the meaning is totally different. After that change I'm all for :shipit:

[teamon]

I'm saying whatever - just keep it consistent across whole project and README

On Sunday, 18 August 2013, Adam Stankiewicz wrote:

I would argue about sample vs example. Imho latter is better (more canonical) although one letter longer.. And the meaning is totally different. After that change I'm all for [image: :shipit:]

— Reply to this email directly or view it on GitHubhttps://github.com/monterail/guidelines/issues/156#issuecomment-22832169 .

[jandudulski]

@teamon :shipit:

[chytreg]

@teamon pls commit and close!