ProjectQ-Framework / FermiLib

FermiLib: Open source software for analyzing fermionic quantum simulation algorithms
https://projectq.ch/
Apache License 2.0
86 stars 38 forks source link

Broadening gitignore #60

Closed ncrubin closed 7 years ago

ncrubin commented 7 years ago

Gitignore did not flag installation files and intermediate files such as checkpoints for ipython notebooks and built sphinx documentation.

Update to the gitignore will prevent developers commiting the checkpoint files , environment files, sphinx documentation, etc.

damiansteiger commented 7 years ago

@babbush I don't think most (if not all) of this new stuff should be in .gitignore as mention previously #26 . It is unnecessary and makes it look ugly.

babbush commented 7 years ago

Haha, ok then. I don't particularly care either way. If you want to roll it back though please do it tonight because I will accept more PRs tomorrow.

ncrubin commented 7 years ago

Hi @damiansteiger

Maybe you could describe to me what is "ugly" about it? That is a non-technical term so I'm having difficulty parsing specifically what you would like to see in PRs in terms of stylistic requirements. Do you have a bullet somewhere in the style guide that you could point me to?

As to the utility of the extra stuff in the gitignore, I think most of it is useful. Assuming you want the code installed you'll probably need some lines in the gitignore about ignoring egg files generated at install. Assuming you want people to run the ipython notebooks you'll probably need to ignore ipynb checkpoint files. Assuming you want people to build the docs you'll need to ignore the build files for sphinx. Assuming you want someone to run pytest you'll need to ignore the pycache generated by the tests.

There are some other ignores that I would imagine are also useful. Ignoring virtual envs created by users when experimenting with Fermilib. Maybe also looking at coverage for testing. Any of these extraneous files would either need to be purged manually by contributors or cleaned up by the maintainers when moved to master. I think rewriting history in this manner would be annoying/difficult.

I agree, that there is probably some extra stuff in the gitignore that doesn't need to be strictly there. I pulled this from the github .ignore repository. I've stripped out some things like Django and Flask ignore content that was obviously not necessary. sites/ might not be necessary and pyinstaller stuff might also be extraneous.

If this gitignore is super offensive (either because it is 'ugly'--whatever that means--or lacks the core functionality of what a proper gitignore is supposed to achieve) then I would ask the "main" contributors to please provide a sufficient gitignore that does not require a manual purging of install files and test files before committing to dev.

damiansteiger commented 7 years ago

Dear @ncrubin

I've left the comment for @babbush as he was reviewing this change as a reminder to keep the code to a minimum of what is required. I didn't intend to offend you and I am sorry you felt this way. It is not important enough otherwise I would have made changes. There is nothing wrong with your suggestion to broaden the gitignore.

If you use git add -u it doesn't matter if there are files around which are not in gitignore. And if you create a new file git add new_file. But obviously a minimal gitignore is always great to have.

Regarding specific things:

We can leave the gitignore like it is.

ncrubin commented 7 years ago

@damiansteiger No offense taken, I just needed clarification on what I perceived as a necessary addition to the changed file.