420
yes (lemmy.ml)
submitted 1 month ago by to c/programmer_humor@programming.dev
16 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 50 points 1 month ago (10 children)

Nonono. This makes sense.

It ignores all other gitignore files in all subdirectories.

It would be one way to enforce concentrating all ignores into this file (or its ancestors).

  • permalink
  • fedilink
  • source
  • hideshow 10 child comments
    •
  • [–] 23 points 1 month ago (9 children)

    Had a quick playaround with it:

    • Yes, that does prevent gitignore files from being committed.
    • It does not prevent locally-created gitignore files from being applied.

    But I'd say the latter is overall a good thing, as some build tools will do a echo "*" > build/.gitignore to have their build-folder add itself to the ignore-list.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 9 child comments
    •
  • [–] 12 points 1 month ago (3 children)

    Ooh, uncomittable files are still honoured. That's mildly interesting, I can see it being both useful and maddening.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 15 points 1 month ago (1 child)

    Git ignore doesn't prevent things from being committed it just prevents them from being "tracked" (for lack of a better word) by default. If you manually explicitly add the file to a commit, and then commit the file will be tracked despite matching the ignore

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 1 month ago (1 child)

    What's the benefit of scripting the wildcard gitignore over just adding build/ to the root gitignore? I guess being build directory name agnostic?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 1 month ago

    Well, if you're the build tool that creates that build-folder, then it just means you don't need to bother your user with adding it to the root gitignore.

    One time, I implemented it for basically a repo-specific download cache folder. Ideally, my users don't need to know of that folder at all.

    Or recently, I implemented it for a build tool where my users might not be devs. They might not use Git at all, or not be very adept at it, so I'm glad to not need to document it...

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 1 month ago (2 children)

    Does it prevent the initial .gitignore from being commited too?

    For example, what if a file name had sensitive information. It's bad practice, but someone might want to ignore the file while also hiding the ignore rule itself.

    /test/fake-person-first-last.json
/test/real-person-first-last.json

    Someone might want to selectively omit the second file while keeping the first, but not show what they are hiding.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 6 points 1 month ago

    .gitignore doesn’t prevent things from being committed. It just tells git to ignore files that aren’t already being tracked. And you can easily override that with -f. Putting .gitignore inside of .gitignore will ignore itself (if it’s not already tracked).

  • permalink
  • fedilink
  • source
  • parent
  • [–] 4 points 1 month ago

    If you're an end user, not a build tool, you'd rather want to place that in .git/info/exclude inside the repo. It's effectively another gitignore file, which won't be committed.

    But if you do need something like this for a build tool, then yeah, you can create a file /test/.gitignore with these contents:

    real-person-first-last.json
.gitignore

    Then running git add . just adds /test/fake-person-first-last.json.

    Both /test/.gitignore and /test/real-person-first-last.json would be ignored right away.

  • permalink
  • fedilink
  • source
  • parent