[–] 2 points 3 weeks ago* (last edited 3 weeks ago) (1 child)

You are right. Everything stated, (while missing the point), was correct.

Arizona is a state. Factually correct. Does it belong here? It must. It's factually correct.

Here is a point for you:

.

Be sure to miss it πŸ˜‰

You're still focused on the tree, consider the forest someday.

Good luck in life my friend.

  • source
  • parent
  • context
  • [–] 1 point 3 weeks ago* (last edited 3 weeks ago) (4 children)

    You're right, 1.5MiB isn't a lot. No one is saying it is. The larger point that you are missing is:

    bloat_MiB = 0
    for (( discussion=1;discussion<101;discussion++ ));do
    echo "i noticed the dependencies grew by 1.5MiB, should we address that?"
    echo "1.5MiB isn't a lot, let's not think about it."
    bloat += 1.5
    done
    echo "where did this bloat come from?"

    You're focused on 1.5MiB and missing the larger discussion.

    My question is, are you engaging with the discussion or are you attempting to be right? Yes. One instance of 1.5MiB isn't bloat, but it is a symptom of bloat.

    Users here are discussing a mindset of ignoring optimization, and many responses are missing the forest (bloat root cause) to focus on the trees (the 1.5MiB example used for demonstration purposes only). Ironically embodying the very mindset which contributes to the bloat root cause. It's amusing, in a way.

  • source
  • parent
  • context
  • [–] 15 points 3 weeks ago* (last edited 3 weeks ago) (1 child)

    This opinion is wrong and person should feel bad.

    Did some more work to fix up his previous, unfinished work, and did git commit --amend (good, we don’t like dozens of commit messages like β€œoops I forgot this bit”, and squashing at the end is more complicated).

    Can't tell if joke. Doesn't seem to be. New branch and push amend, drop old branch, solved. The complaints seem to be, "I don't want to understand git's rigid workflow, instead I want it to intuit what I want. Just overwrite my shit without asking! It's more convenient that way!"

    Who the hell wants presumption in their source control? I want that behavior as rigid as law.

    Remote is truth. Remote is immutable.

    Also, are they legitimately complaining that they don't want small commits? Small commits are best practice because they create granular and traceable history.

    This person needs to:

    1. Stop expecting a tool to adapt to every user's presumptive flow, and instead adapt to the tool.
    2. Define a commit workflow that resolves granular commits into sensical messages.
    3. Don't use force args on remote unless you're the admin and know the potential consequences, ya muppet.

    All this effort to avoid learning and conforming to the standard workflow. Seriously one of the worst opinions I've ever seen. Congrats.

    I think the source of this person's struggle is their own misguided opinions. If they paused and thought, "Why does git do X that way..?", it would become clear. But who has time for that. Thrash and shout.

    TLDR: If git solution is so bad, solve it better.

  • source
  • [–] 4 points 4 weeks ago* (last edited 4 weeks ago)

    You can't set permissions and ownership because NTFS doesn't support Linux style permissions and ownership.

    Why not copy the data elsewhere, format drive to ext4 or btrfs, then copy the data back? Don't use NTFS on Linux unless you enjoy having less control, unless you're sharing the drive with Windows then you have no choice I suppose.

    TLDR: NTFS bad (not really, but sort of).

    If you are staying on NTFS, you can stop reading here.

    Anyway if you decide to migrate off NTFS, and assuming your username is zapBrannigan:

    (recursively sets user ownership to zapBrannigan, sets group ownership to root, setting the group to root is a nice default because it's effectively "no group" and limits access to non-privileged, non-you users)
    sudo chown -R zapBrannigan:root /path/to/drive

    (recursively sets user, group, other permissions, where 664 corresponds to "allow rw-rw-r--", in this representation, the mode bits 664 are a binary mask, 6=110, 4=100, so you're setting 110110100 which sets the allow described above)
    sudo chmod -R 664 /path/to/drive

    The first command sets ownership to you, the user. The second command allows the user to read and write every file, and other users to read every file, set to 660 to forbid other users.

    After that I suspect your fstab issue will become solvable.

    If anything scares you, audit the data and backup the critical segments before working with the drive. I am assuming you don't have free space to backup the entire drive, if you do, then just do that.

  • source
  • view more: β€Ή prev next β€Ί