Show more

Guess how much this burger is sold for (US dollars, Philadelphia)

Link me to a reliable peertube instance you like

If you learned anything today, it's that shell scripts are awesome! And as soon as you encounter a binary file format, SHELL IS NO LONGER APPROPRIATE

So I was going to use this to tell you how git internals work by implementing them with simple shell scripts

Then the git index ruined my hopes and dreams

Do NOT read this code to learn how git works.

Not that anyone would ever want to read through this garbage

Okay, I think I worked out the major bugs and the shit repo is now properly browsable on the web

Reading the git index in a POSIX shell script

This was a good idea, right

This sounds like a good idea until you realize what git's index format is like

I claimed earlier that you could implement git with shell scripts inside of an afternoon

So, uh, let's do it

live.drewdevault.com

It would be nice if Mastodon automatically untagged people when you reply to a thread they haven't participated in for N messages

"Note: Since the split() function instantiates a shlex instance, passing None for s will read the string to split from standard input."

What the fuck, Python

Fun fact: even git push -f doesn't lose data, either. The server keeps a reflog just like your local repo does. You can git reset --hard master 'master@{1}' on the server to undo a force push.

@sir 3. use full disk encryption and forget your passphrase.

It's also worth knowing that you can implement a useful subset of git with shell scripts, inside of an afternoon. This is how large swaths of git were implemented in the early days!

There are only two ways to lose data in git:

1. git add, but never commit what you aded. Perhaps you git add, then make more changes, then add again before you commit. The objects from the first `git add` will be lost on the next gc.

2. rm -rf .git

A lot of people are confused by git. Most of these people, I reckon, learned it from the outside in - from the command-line interface down. If you started with git by asking "how do I sync up my changes with my peers", then you might get the answer, but you will be missing the foundation on which that answer is built. This is the main source of confusion with git.

The better way is to learn git from the inside out. You should first learn about what objects are and how they're stored and identified, and how they relate to each other. You should learn what blobs, trees, and commits actually are, and how they relate to each other, and how commits form a linked list from which a graph of all objects can be derived.

Then you should learn how the ref database gives friendly names like "master" and "feature/foobar" to objects, and how the reflog tracks changes to references over time.

THEN, and only then, should you learn how to use the CLI. Then you can learn about using the staging area to add objects to the database and create commits, and how doing this updates the reflog.

Git makes total sense when you approach it from this angle. Supposedly hard tools like git rebase are totally understandable when you view them with the appropriate foundational knowledge.

Git is a tool which you will reach for hundreds of times a day, every day, for your entire career. Maybe it's worth learning about properly.

Idea: NFC receipts as an alternative to paper receipts

I don't want to give you my email address, but you encode the receipt data onto an NFC pad I can tap my phone to, we can save paper without giving you that oh-so-tasty data

The CA Attorney General is investigating ICANN after the .org heist, here's hoping they take the entire board and drag them by their entrails right into jail

Show more
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!