.gitignore should contain quarto create project build artifacts

[kdheepak]

Description

Currently this is the only content in .gitignore.

/.quarto/

But when creating a book, _book should also be in .gitignore otherwise users accidentally commit that to the repo. Ideally, this should be updated whenever a new project kind is added to _quarto.yml but I can imagine that being more work.

At the very least, the default build folder should be ignored.

[mcanouil]

Thanks for the feedback.

In the future, please search before opening new issues/discussions:

• Improve how Quarto handles .gitignore to keep it clean #6011

But when creating a book, _book should also be in .gitignore otherwise users accidentally commit that to the repo. Ideally, this should be updated whenever a new project kind is added to _quarto.yml but I can imagine that being more work.

You might not want to version control the output but your case is not general enough.
For example, if a user changes output-dir to output to docs because of GitHub pages deployment from the default branch. Why would Quarto add _book to. .gitignore?
Same goes for _site. In my opinion, adding output to .gitignore will cause more headaches to more users.
If you don't want it, add it yourself to .gitignore.

[kdheepak]

imo having excess information in .gitignore is not really an issue and is pretty common. For example, it's pretty common to have the following in .gitignore for python projects:

### Python
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class

# C extensions
*.so

# Distribution / packaging
.Python
build/
develop-eggs/
dist/
downloads/
eggs/
.eggs/
lib/
lib64/
parts/
sdist/
var/
wheels/
share/python-wheels/
*.egg-info/
.installed.cfg
*.egg
MANIFEST

# PyInstaller
#  Usually these files are written by a python script from a template
#  before PyInstaller builds the exe, so as to inject date/other infos into it.
*.manifest
*.spec

# Installer logs
pip-log.txt
pip-delete-this-directory.txt

# Unit test / coverage reports
htmlcov/
.tox/
.nox/
.coverage
.coverage.*
.cache
nosetests.xml
coverage.xml
*.cover
*.py,cover
.hypothesis/
.pytest_cache/
cover/

# Translations
*.mo
*.pot

# Django stuff:
*.log
local_settings.py
db.sqlite3
db.sqlite3-journal

# Flask stuff:
instance/
.webassets-cache

# Scrapy stuff:
.scrapy

# Sphinx documentation
docs/_build/

# PyBuilder
.pybuilder/
target/

# Jupyter Notebook
.ipynb_checkpoints

# IPython
profile_default/
ipython_config.py

# pyenv
#   For a library or package, you might want to ignore these files since the code is
#   intended to run in multiple environments; otherwise, check them in:
# .python-version

# pipenv
#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
#   However, in case of collaboration, if having platform-specific dependencies or dependencies
#   having no cross-platform support, pipenv may install dependencies that don't work, or not
#   install all needed dependencies.
#Pipfile.lock

# poetry
#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
#   This is especially recommended for binary packages to ensure reproducibility, and is more
#   commonly ignored for libraries.
#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
#poetry.lock

# pdm
#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
#pdm.lock
#   pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
#   in version control.
#   https://pdm.fming.dev/#use-with-ide
.pdm.toml

# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
__pypackages__/

# Celery stuff
celerybeat-schedule
celerybeat.pid

# SageMath parsed files
*.sage.py

# Environments
.env
.venv
env/
venv/
ENV/
env.bak/
venv.bak/

# Spyder project settings
.spyderproject
.spyproject

# Rope project settings
.ropeproject

# mkdocs documentation
/site

# mypy
.mypy_cache/
.dmypy.json
dmypy.json

# Pyre type checker
.pyre/

# pytype static type analyzer
.pytype/

# Cython debug symbols
cython_debug/

# PyCharm
#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
#  and can be added to the global gitignore or merged into this file.  For a more nuclear
#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
#.idea/

Or see examples at https://gitignore.io, e.g. https://www.toptal.com/developers/gitignore/api/python

If someone changes output-dir or configuration, they can augment a default .gitignore.

I've seen two related issues enough times that I imagine it's not uncommon.

1. During quarto render a user has done a git add . && git commit
   • This typically is a user that is using quarto preview and accidentally commits some intermediate files that quarto creates for .qmd executable files or .tex files
2. After quarto render a user does git add . && git commit

When I'm introducing quarto to a team and recommending they start a project in quarto, these are papercuts I've seen from some analysts or researchers, particularly people that are not familiar with git.

[mcanouil]

If I may, instead of having a very long exclusion list that is almost not maintainable, I would use an "exclude all but ...".
This way you focus on what you want to keep instead of everything you might want/need to exclude.

Also note that I am not saying that your use case/feedback does not make sense.
Simply look at the other thread and you'll see that there is no "right answer", so if you teach Quarto and you know your audience, feel free to add some guidance about Git and your audience use cases. In my opinion, it would be more valuable to them than any opinionated default .gitignore.