Hacker News Reader

Comment by AndrewOMartin | Hacker News Reader

This is one of those "explanations" where, if it's a concept I'm familiar with I can apply my knowledge to it and see that it mostly checks out, but if it's something I don't already know, I find completely useless.

View on HN

Personally, as someone who has been sketchnoting for about 5 years, I feel the point of sketchnoting is more to create a condensed visual reference of an idea for personal recall than for teaching that same idea to someone else.

There's a wider argument here of whether notes should be used for personal recall or general reference. I tend to lean towards the former, but there's more nuance here.

I'm working on a blog post that discusses how to take good sketchnotes and breaks down this argument a lot further, but it's already super long and far from being finished... perhaps I'll finish it someday, haha.

Kudos to the original author of these notes. When taking these types of notes, you have to think about what to leave out as much as what to leave in. I think that concise notes in this style to show that the author has a deeper understanding of the subject than the notes convey on the surface, especially when the point of these notes are to compress one's knowledge on the subject into a concise visual representation.

Sketchnotes are macroexpand for the brain :P

As a designer. I don’t understand these. I know the overall concept of using git but this didn’t bring me any aha moments.

Agreed. Explanations of git sometimes remind me of monad tutorials.

I suppose you could combine the two by pointing out that git is like a category where a git merge is like a pushout etc.

Git is simply a directed acyclic graph of commits with pointers, stashes, a few named data stores and two quasi-recursion mechanisms.

“A monad is just a monoid in the category of endofunctors.”

"It's like a burrito!"

For the unfamiliar: https://www.google.com/amp/s/byorgey.wordpress.com/2009/01/1...

Exactly. I use basic git daily, but I'm still confused about rebase.

I gave up. I determined some of us are just too stupid to do quantum physics or rebase in git without destroying our branch. I'm one of those people.

FWIW Git is harder to understand than basic quantum mechanics IMO.

The latter has been optimized with good notation and has a fairly simple structure, whereas Git is a beautiful idea wrapped in an API from hell

Rebase is copying a series of commits and pasting them onto somewhere else. By default it will copy commits and apply them onto the new upstream.

In other words, go from

            old                 your
           master              master
    ----*----*----A----B----C----D
              \        
               \          new
                \        master
                 \----*----*

            old               your old
           master              master
    ----*----*----A----B----C----D
              \        
               \          new                 your
                \        master              master
                 \----*----*----A'---B'---C'---D'

Interactive rebase allows you to choose to reorder, rename, combine or drop those commits A, B, C, D as they are applied to new master.

For me it's the other way around. I mean, it's like one of the few commands which says what it does: re-base. Makes all kind of sense to me: take what you have and put it on top of something else. So same as a bunch of cherry-picks, etc. It was one of the first concepts I undesrtood. Merge on the other hand I understand as well but it leads to graphs I can't understand without spending some time looking at.

Rebase is just replaying the diff associated with each commit. It’s like a batch cherry-pick and that itself might be a conceptually more straightforward place to start.

This is great. IMO “replay” is a much better description than “copy.”

Technically more appropriate than copy as a commit is immutably wedded to its history by the chain of hashes preceding it.

FYI replay is the term used in the git docs, which otherwise make little sense.

rebase cherry-picks more than one commit, as in "git reset c; for commit in a..b; do git cherry-pick $commit; done". With sensible defaults for a, b and c, they can often be left out.

Someone will correct me, hopefully, if I'm wrong:

Rebase means moving the branch point of your feature branch to later on the main branch.

Let's say you create feature branch foo from main on 2021-08-01. You do work. Others do work and add them to main. On 2021-09-18, you rebase foo onto main. This has the effect of re-writing history! There's no longer a branch point at 08-01, it's been moved to 09-18.

https://www.atlassian.com/git/tutorials/merging-vs-rebasing

Rebase is not always the best option. I personally prefer merging, and that has worked for 100% of situations I've found myself in so far in my DevOps career.

> Someone will correct me, hopefully, if I'm wrong:

> Rebase means moving the branch point of your feature branch to later on the main branch.

It refers to a more generic action/set of actions, where this description is one possible end result. Granted this is probably the most common use, and the name "re-base" definitely fits this usage best.

The more generic action is something like "take a set of commits in one place in the git history, and reapply them somewhere else in the git history, optionally dropping or rearranging some of them in the process".

It's strangely wonderful to me that people can have so many different ways of explaining this action/concept. Your description is definitely more accurate than mine :)

The most useful way for me to think about a rebase is "replay my commits over an updated branch, as though I started coding when those updates had already happened"

So if you check out on day 0 and rebase on day 5, then it becomes "pretend I started coding on day 5 in the first place, and let me correct any contradictions (conflicts) as though I was making those decisions as I was making each commit".

I still struggle but this helps me conceptualize it.

Tip: Create a new branch before you do the rebase, if you fuck up the rebase with bad merges or dropped commits it's easier (i.e. more intuitive) to unfuck by just using the backup branch you made prior to your rebase instead of messing around with `git reflog`.

Reply on news.ycombinator.com