• 25 Posts
  • 1.36K Comments
Joined 6 years ago
cake
Cake day: May 31st, 2020

help-circle


  • 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.


  • 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…


  • 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.




  • Ephera@lemmy.mlto196@lemmy.blahaj.zone•Mosquito rule
    link
    fedilink
    English
    arrow-up
    17
    ·
    2 days ago

    A week ago, I took a walk through some nearby woods, came back home, took my jacket off, then found this kind of bug on the floor, with one of its hind legs missing:

    Stink bug with brown coloring

    So, I assume, it latched onto me during my walk.

    Anyway, I caught it and yeeted it off the balcony. Problem solved.

    Next morning, I walk out the front door of our house and see the same bug sitting on a wall there, with the same hind leg missing.
    The front door is on the other side of the building, so I thought, huh, funny coincidence that you traveled quite a few meters, but still stuck to the same building.

    Yesterday morning, I suddenly hear an insect in my appartment. It sounded like a fly beating its wings. I was really confused, because I have flyscreens on all windows. I only had the balcony door open for a minute in the previous evening.

    Anyway, you guessed it, it was the same bug again, same hind leg missing. Getting a bit creepy now. 😅

    I yeeted it off the balcony again, but if it shows up another time, I’ll have to carry it back to those woods and hope that it doesn’t find its way back…





  • Had to think about it for a moment, but I would say the fundamental problem with adding more content to Minecraft is this classic game design quote:

    Given the opportunity, players will optimize the fun out of a game.

    Source

    In early days of Minecraft, you would cut down a tree, then slap down 6 blocks of wood and that was your table. It looked fine, because everything was just blocks and the few available blocks all could be combined without it looking terrible.

    Now you’ve got a magnitude more blocks and the player looking to ruin their fun will spend far too much time:

    • Choosing colors to combine. It can’t just be wood, it’s gotta be jungle wood, to make it fit in with the orange color highlights.
    • Choosing block shapes. Can’t just be a regular 1m³ block, it’s gotta be an upside-down stair. And a carpet on top as a table cloth.
    • Farming those resources. You need to find a jungle and a sheep. And scissors to collect the wool. And then you need to craft those stairs and carpets.
    • Placing blocks. An upside-down stair can’t just be slapped down. Instead, you need some scaffolding against which you can place it from the correct angle. Nope, not that angle. Gotta remove the stair and place it anew. And don’t forget to remove your scaffolding afterwards. And place back those blocks you had to remove to get to the correct angle.

    There are folks that find it relaxing to mine for hours and to spend hours getting every detail perfect about their build. But even those folks presumably wouldn’t call it fun.

    But of course, your community will still ask for ever more hyperspecific blocks to be added, so they can optimize the fun out even more. Because your community are not game designers.


  • They always felt kind of weirdly similar to me, even the games that they just ended up buying. Hard to describe, but the games always felt rather ‘functional’, rather ‘game-y’. Kind of like what I think of as solid AA games, just scaled to AAA.

    Like, I don’t know, Hellblade is about mental illness and kind of made up to be this cinematic experience, so it should be a massive exception to this, but then it’s wrapped in this hack’n’slash gameplay and has the name “Hellblade”, as if they were afraid it might flop, if it doesn’t promise your usual dose of generic/violent gameplay.

    Hell, Minecraft feels like it got microsoftified, in that they just keep adding more and more stuff to it, with no clear direction. It’s just, oh, the community wants XYZ, let’s add XYZ.

    I guess, maybe that’s part of it? They have a lot of money, so game studios just add all kinds of features rather than making hard decisions on what kind of game they want to be.
    That’s obviously also very positive in many ways, but yeah, might ultimately lead to the sameyness…



  • Had to just think about why #[non_exhaustive] exists, so perhaps this helps you as well:

    Imagine you’re developing a really important core library, something like TCP. And then other libraries depend on your library.
    Now, if you change your implementation, you may need to introduce a new error case, even though the rest of the API still works the same.

    You have two choices to deal with that:

    • Release version 2.0, because that’s a breaking change. Each library that depends on you needs to manually upgrade to version 2.0. Some never will, because they’re unmaintained. Any application that ships your library as a transitive dependency will need to ship both, version 1.0 and version 2.0, for the next few years until the last of their direct dependencies has upgraded to 2.0 or been removed.
    • Or: You’ve declared that error enum #[non_exhaustive] before going 1.0 and therefore forced all depending libraries to implement a default match case. You can sneak in the new error case in version 1.1 without all those depending libraries needing to manually upgrade. The ecosystem does not split in half between 1.0 vs. 2.0.

    Obviously, if it’s a really egregious new error case that needs specific handling, then you might still want to release version 2.0, but by adding the #[non_exhaustive], you can decide later on and if you are such a central library, there’s definitely going to be situations where you want to make use of it.