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.

@b0rk Janitor. I always enjoyed having someone who likes to do boring repository / code maintenance to relax. Makes everything neater, and makes it easier for us ADHD devs who would burn out on it.

@b0rk I'm a blend of Loud Noob, Documentarian, and Read The Entire Internet.

Don't let me near code, tho 🤣

@b0rk how about the Test Writer?

The one that writer clear tests that illustrate how things are supposed to work (as opposed to how they are working)

@b0rk https://spderosso.github.io/onward13.pdf

@b0rk tbh I think a significant amount of it is their incredibly unique-term-infested manpages. Learning git via normal means is a ridiculously large investment before you get any benefit.

https://git-man-page-generator.lokaltog.net/

@b0rk I dont find it too bad, but I do find it inconsistent; e.g. git tag and git branch both have -d for delete, but for git remote you have to do 'git remote remove' Similarly git branch -m to rename vs git remote rename. git push onto non-default branches also confuses the hell out of me.

@b0rk i had a unit on unix system administration where each week we got a slightly broken VM, one per student, we had to fix. every week was slightly harder culminating with a totally broken PAM so you couldn't easily log in

we couldn't break anything, it was already broken! and if we broke it too much prof would just re-image the VM. so no fear!

@b0rk tested regular backups.

@b0rk most starters like things like #tmux - #bash-insulter (its fun) and #cmatrix and the obvious
telnet towel.blinkenlights.nl
and for people which go the extra mile, either #adb with #scrcpy for android fun or the limitless options of #yt-dlp
(spice up your music collection with some yt-dlp -x <LINK>
or choose smaller / bigger quality with yt-dlp -F <LINK> ... so much more fun tha any limited and fastly outdatet gui/addon)

@b0rk is there a way to permalink an archived tweet?

I cannot be the only person who finds linux on the desktop annoying and hard to use sometimes, I love linux but it can really be the worst

@b0rk holy cats, this is a mood

@b0rk is she a sister of the data witch? @djnavarro

@b0rk tar, but with the correct flags first try!

@b0rk this gave me the idea alias b0rk=strace 😀

@b0rk (mailbox server is a single point of failure; unfortunately all of the similar systems have this problem; you basically use an external server as a meeting point)

@b0rk yeah very handy tool. We enroll it to everyone during our onboarding in our company.

@b0rk @kaasbaas thank you