Skip to content

.gitignorganization #1300

Open
DanGould/rust-payjoin
#18

Description

@benalleng

From some post merge discussion I don't want to get lost. #1295 (comment) I think it would be helpful to come to a consensus on how we want to organize and document our gitignore. Though not mission critical I think a well organized gitignore can sometimes be helpful to make sense of all the generated files strewn about in a large repo.

Here are the docs in case there is some useful knowledge to be gleaned from there https://git-scm.com/docs/gitignore

Some things to consider.

  • Should we have one large gitignore separated in blocks for each workspace or should each workspace have its own gitignore?
  • How much documentation should we expect to explain why some files are ignored?

Activity

  1. nothingmuch commented on Jan 26, 2026

    @nothingmuch
    Contributor

    i vote for separate files in subdirectories, seems more organized and easier to maintain organization as they grow

    fwiw a good acceptance criteria should be that you don't have to do anything to start working with jujutsu on any part of the project

  2. spacebear21 commented on Jan 27, 2026

    @spacebear21
    Collaborator

    I agree with separate .gitignore files per directory. Adding explanatory comments for each line of ignore would be useful.

  3. added
    good first issueDoes NOT mean "an LLM can do this." Please discuss the constraints and intended approach.
    on Jan 27, 2026
  4. Hamza1610 commented on Jul 7, 2026

    @Hamza1610

    I have been look into this, andit occurs to me that I agree with @nothingmuch, because as the project keeps becoming larger the more .ignore filewill. Better documentation will be required for each workspace.
    @benalleng I wil like to know what is the consensus. I think I can handle this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationgood first issueDoes NOT mean "an LLM can do this." Please discuss the constraints and intended approach.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions