@b0rk I recently implemented a db struct based on the sqlite article you referenced, and this is how it came out: https://gist.github.com/llimllib/2d03a8da46bbd3d247d2492849e3dc4e

I'd love to see how other people have implemented it!

@b0rk thanks, I'm using mux routing but my handlers can be a bit complex so this will help simplify them

@b0rk Hi Julia, I was curious to know how you built the categories thing in your blog page. Is the website open sourced, I'd like to have a peak and implement it in my own as well :p

@b0rk git-diff can be used with the files outside of the repository and you probably already know about its --color-words option.

Otherwise there's https://github.com/ymattw/ydiff and is multiple forks called cdiff.

@b0rk `git diff --no-index before after` can be nice too, if you have configured a nice diff pager like delta!

@b0rk https://github.com/so-fancy/diff-so-fancy

@b0rk
Watching from afar, I admire you for trying it, and admire you more for the success you are finding. Well done!

someone asked me recently how long it took me to get used to the rhythm of working for myself and I said “uh, maybe 3 years?”. I thought working for myself would be hard to adjust to and it was, but I'm happy I did it anyway

@b0rk Keep up the great work! 😄

@b0rk I was sitting next to another programmer who, after much trying, threw his hands up and exclaimed, "Well, it won't work," then a half-hour later had it working. A puree of 2 and 4.

@b0rk

Cool, but where's the rubber duck?

@b0rk Love this and purchased! Literally just went through a problematic debug yesterday and thought of this.

@b0rk I also came to the Emacs strokes late, as a Vim user. one great thing about learning them is that they work in a lot of macOS UIs too. In particular ctrl-p/ctrl-n

@b0rk thanks for the post. I learned new things from it. I love your approach to learning.

I did a similar investigation some time ago. In the end I made a game in the terminal to make it more interesting. :)

https://youtu.be/WvSOSyi5lWY

@b0rk CTL-[ is still how I type ESCAPE, due to too many years of odd keyboard layouts.

@b0rk The color scheme might clash with the rest of the room, but I love the idea.

@b0rk I was wondering if this was Risograph, or something similar, because it feels so perfect for that. Awesome.

@b0rk For me personally, this is missing step 0: Take a shower, take a walk, have a cup of tea, take a nap.
Can be combined in any subset or order, as long as it gets you away from the machine for ten minutes.

@b0rk Thank you so much!

@b0rk !!!!!

anyway i've been trying to summarize my relationship with git (which I love) in a single panel and this is where I landed today

@b0rk

@b0rk Oh that is awesome. I've definitely checked things in to the wrong branch. I just pulled up the Git Bash terminal (I'm limited with what I can access, on $work machine) and it includes the (branch) thing!

@b0rk that's very good advice

@b0rk I voted command line + GUI, with the latter being for my Magit usage (and I guess Github blame view). I use the command line for pull, rebase, log, diff, and many blame operations. I use Magit for committing things, especially selective commits, and thus for checking diffs before I commit and so on. (And some use of git-timemachine in Emacs to move back and forth through the history of a file to track things.)

But my git use is odd since I track and monitor a lot of upstream repos.

@b0rk I have used @fork_dev for the last 5 years or so and I can't be any happier

@b0rk

I work in IntelliJ, and it’s Git UI is so good (or I spent enough time to get used to it’s rough edges, too), that I feel much less productive on the CLI.

I wonder why IntelliJ users still use the git CLI, esp. for staging, writing commit messages, diffs and git blame.

But also branch operations and git log are good enough or even really good, depending on the use case. I totally recommend the interactive rebase UI!

@b0rk FWIW I like reading your posts. At the moment, I really need reading about tech stuff from the perspectives of people who *aren't* total assholes.

For myself I gave up on writing anything substantial online for many reasons, one of which is that I don't have the psychological constitution for potential large audiences (and hence, maintaining a "real" social media presence). I wish it wasn't like this, and I hope doing what you do doesn't burn you out.

@b0rk I feel you. Try to ignore this stuff if you can. You're doing important work here 🙏

@b0rk This has been my experience as well. And I’m a middle-aged white dude. I imagine it’s even worse for people in other demographics

@b0rk Thank you! This is so much clearer than any of the many other explanations I've tried to read before now.

And I hadn't even heard of squash: I was just trying to understand the difference between merge and rebase... (Yes, I put off learning git about ten years longer than I should've.)

@b0rk There's a fourth option though: The "student has their first merge conflict, panics and tries to sort it out themself instead of asking for help"-option.

- Checked in conflict-markers: ☑️​
- Checked in backup and temporary checked-out files for git merge-tool: ☑️
- Merge commit that only contained the changes of only one branch ("ours"-strategy wasn't intended): ☑️
- Merge commit that contained the content of a unrelated third branch, but non of the changes of the two merged branches: ☑️

@b0rk Perfect. What an elegant way to represent commit graphs. And thank you for articulating my dread of merge graphs

A squash + rebase looks almost ideal to me. I'm going to do that more often.

The negatives of squash + rebase look minor to me though. Is a 3000-line PR any better with the other options?

@b0rk so every time you touch a file, there is a whole new copy in a blob? 😨😱

@b0rk this is making me want to finally sit down and work through https://shop.jcoglan.com/building-git/ where you build a simplified working git clone

@b0rk great content! (As always). I recently found https://pre-commit.com/ as a really useful tool for distributing coding standards inside a git repo. A bit different than what your current content, but one of worst sort of merge conflicts on teams is formatters gone rogue, IMO.

@b0rk Thanks, I liked that! This post woke something in me re the discussion on rebase vs merge the other day. I think I prefer rebase/linear history because it maps very well to a sequence of patch files that could be copied around and applied independent of git itself. Not sure why that feels so "pure" to me, but it does.

@b0rk I think of them as patches

@b0rk
Really nice blog, and yeah, confirmed, there's a stark difference between the mental model (I'm one of the "all of the above" folks) and the actual technical model.

Speaking of this, before git, I worked a lot with monotone, which has quite a lot of similarities to git... however, storage wasn't one of them. Monotone stored commits as diffs, so there were situations where they had to be replayed en masse. That could be quite a performance hit...

a bunch of folks have mentioned that they use rerere to avoid solving the same merge conflict a million times during a rebase. If you use it, do you find it works well? are there any downsides to using it?

@b0rk If rebase is going badly I sometimes do `git reset main` instead and craft the commits I need. A lot of the times it’s a single commit anyway!

@b0rk I literally told my 2 juniors today to stop force-pushing rebased versions of their PRs to GitHub if there are already comments on some of the old commits, and to instead merge over them... turns out a lot of nice GitHub stuff breaks when you rewrite history

@b0rk I noticed the print discount didn't work on Linux Toolbox. Is that an oversight or am I kvetching?

@b0rk I ordered a couple! Thank you!

@b0rk these are excellent, i had to get them all! :flan_dalf:

@b0rk "confusing git" is redundant

@b0rk Another great article, thanks for writing and sharing.

With checkout the '--' can be used between a branch and a file on that branch and it will copy that file from that branch to the current one. Kind of like cherry-picking files rather than whole commits.

git checkout -b new_feature # Create and checkout a new branch
git checkout old_feature_branch -- path/to/file/in/old_feature_branch

#git

@b0rk This is very helpful for git newcomers. The one that always terrifies me is getting "yours/theirs" wrong.

@b0rk I'd only say that for me, I only push to main for something like my personal site and minor changes. Otherwise I use branches even on tiny teams or if working on a feature that is more than a minor change.

@b0rk slight variation on your big team... which would be similar to most open source on gitlab\hub = fork with feature branch

For a different angle, the Git Book also talks about some of these internals in its chapter on Git Objects.

I recently leveraged that to manually update permissions in a Gerrit setup, which stores its user database in a unusual Git repository.

https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

@b0rk :6th senses: “I see databases.”

@b0rk This is a thorough explanation of how git works! It's nice to learn a few things too.