search

getkirby / demokit

A demo setup for trykirby.com
https://trykirby.com
25 stars 12 forks source link

Remove *.sublime-project from .gitignore #48

Closed trych closed 3 years ago

trych commented 3 years ago

.sublime-project files should generally be checked into version control, see: https://www.sublimetext.com/docs/3/projects.html

texnixe commented 3 years ago

Thanks for your PR. But we generally ignore all IDE specific config files.

trych commented 3 years ago

? This makes no sense from a user perspective. Whenever I clone a plain kit now, one of the first things I need to do is removing that line from the .gitignore file.

Those that don't use Sublime are not affected at all if this is not listed – as they don't have any of those files anyways – and those that do use Sublime have extra work if it stays listed. So I don't see any advantage in having this listed. The most unopinionated would be to have it not listed.

lukasbestle commented 3 years ago

I agree with @trych. This is not about our own code, but also about defaults for users. If I was using Sublime Text, I'd be annoyed by this default as well.

We should also reconsider the other lines in .gitignore for code editors. For example the .vscode directory can also contain project-specific configuration that applies to every developer in the team.

Related PRs for the other kits: https://github.com/getkirby/plainkit/pull/8 https://github.com/getkirby/starterkit/pull/21

trych commented 3 years ago

Related PRs for the other kits: getkirby/plainkit#8 getkirby/starterkit#21

Yeah sorry, was not sure if there is a smarter way to handle this change in three places at once. 🙈

But yes, that's what I mean, some defaults that get as little in the way as possible for the users in their default states. :)

trych commented 3 years ago

@lukasbestle This has been open for a long time (in all the kits) and is still a little annoyance whenever I start a new project. Is there a chance to get this merged? Or should the /.vscode line also be taken out first? What about the /.idea line (I don't know what that refers to, but it also seems setup specific)?

lukasbestle commented 3 years ago

Sorry for the delay. So far we didn't find the time to think the strategy through – I think if we merge it, it should be consistent between all IDEs.

As far as I know, .idea refers to the JetBrains IDEs, specifically PhpStorm. I don't have experience with it, so I don't know what the folder structure looks like and which parts should be committed to repo and which parts shouldn't. @afbora Do you have insights on that as a PhpStorm user?

.vscode is also difficult. As far as I can tell, it can contain both project-specific config and config specific to the user. I haven't found a good overview on that.

Any help is appreciated. I think once we have a clear strategy, we can merge this PR (and the two others for Starterkit and Plainkit).

afbora commented 3 years ago

Sample JetBrains .gitignore file: https://github.com/JetBrains/resharper-rider-samples/blob/master/.gitignore

I don't know much about IDE folders. I don't know which folder keeps which information or which is user data or which is project data.

If the IDE folders will be valid for all users (so project setup not user setup), I think we can remove them from .gitignore. But if it contains custom settings/setup for each user, we should keep it in .gitignore.

lukasbestle commented 3 years ago

Thanks for the link!

To be honest that JetBrains ruleset looks quite complex. And it's also very hard to maintain. There is a huge security risk with sensitive data that is committed by accident.

Maybe we should only remove the *.sublime-project files from our .gitignore and keep .vscode and .idea in – it's better to be secure by default given that users of JetBrains and VS Code can still customize it depending on their project.

trych commented 3 years ago

Maybe we should only remove the *.sublime-project files from our .gitignore and keep .vscode and .idea in – it's better to be secure by default given that users of JetBrains and VS Code can still customize it depending on their project.

I think that sounds good. If somebody has a specific issue with the .vscode folder or so being in the .gitignore file, they can open another issue and explain this specific issue, so that we don't need to make wild guesses what makes sense for these IDEs. As long as nobody complains about those, we could just leave them in.

lukasbestle commented 3 years ago

I'm a bit split on this one. On one hand it would be inconsistent, but if we really try to keep this consistent, we would get nowhere. And so far no one complained about .vscode or .idea as far as I know.

What do you think @distantnative @afbora?

distantnative commented 3 years ago

I would go for it, if it's clear that Sublime is recommended but the others might contain sensitive information. For me that's a good way to draw the line for now.

lukasbestle commented 3 years ago

I've added a comment that only sensitive workspace files are ignored.