raju

This is a great list. As someone who has spoken at hundreds of conferences, there's one piece of advise I give younger speakers, particularly those nervous about how the audience will receive them. Dylan alludes to this in a different context

> Finally: respect your audience. Whether you’re talking to five people at a meetup, fifty at a community event, or five thousand at a huge international conference: those people are the reason you get to do this. They have given up their time - and often a substantial amount of money - to hear what you have to say. They deserve your best shot, every time

This is the same thing I say except, them _choosing_ to attend your talk, and opting in to giving you their time and attention is a signal that they _want_ you to succeed. They are HOPING you deliver your message, and that your demos all work, and that you conclude well. If kept in mind, I believe this can help alleviate some of the anxiety.

Sidebar: I've done this for a very long time and I still get nervous at the beginning of every talk. And I will be the first to admit—you WILL run into the occasional show off in the audience who is intent on demonstrating to you (and to the rest of room) how much smarter or more experienced they are than the speaker. That will happen—but it's an aberration.

I've been a VERY happy customer (no affiliation whatsoever) of Presentify for many years now, which was also a "Show HN" post (yeesh) 5 years ago

https://news.ycombinator.com/item?id=22938604

I am very excited to try Draw Over It—thank you for sharing. I speak at several conferences a year, and also do online workshops and training, and Presentify has been a godsend.

However, the one limitation is if you toggle it, you lose your annotations. And you can't do anything with the underlying app—can't scroll or click buttons. Looking forward to trying this out.

pickaxe isn't a Git command, rather, it's a set of flags that `git log` offers (specifically `-S` and `-G`).

Shameless plug: I recently did a webinar on how the pickaxe options are better than `git-blame`) that you can find here: https://nofluffjuststuff.com/webinar/142/level_up_your_git_g... (Note: It requires you to provide an email address).

Similar HN thread: https://news.ycombinator.com/item?id=42967173

Let me start by saying this is wonderful work. Thank you for creating such a comprehensive resource. I haven't read through it all, but one thing did catch my eye.

Section 5.1 (https://beej.us/guide/bggit/html/split/branches-and-fast-for...)

> The default branch is called main.

> The default branch used to be called master, and still is called that in some older repos.

This is not true. Git still defaults to `master`, but allows you to change the default (for future `git init` invocations via `git config --global init.defaultBranch <name>`)

See https://github.com/git/git/blob/bc204b742735ae06f65bb20291c9...

Again, thank you. If I find anything else, I will be sure to post here.

*Update*: I also feel that referring to "older repos" sends the wrong message. *GitHub* decided to make this change, causing others to follow, and finally Git itself allows for the aforementioned configuration, but it has little to do with _newer_ or _older_, but rather preference.

Posted this comment https://news.ycombinator.com/item?id=42961468

Happy to get any feedback.

Not the OP, but I've been teaching along similar lines. I've done it a couple of times at conferences—here's one of the versions: https://www.youtube.com/watch?v=8Q-frNO-yps

I've also blogged about it

- https://looselytyped.com/blog/2014/08/31/gits-guts-part-i/

- https://looselytyped.com/blog/2014/10/31/gits-guts-part-ii/

If you really get into them here’s a few series that are along similar lines

- Prey series by John Sandford

- Bosch series by Michael Connelly (He’s the “Lincoln Lawyer’s half-brother). Also a series on Amazon Prime

- Orphan X series by Mark Greany

I’ve followed all of these (as well as Jack Reacher and Gray man) series for years and have read all of them. Great brain candy.

Let me start by saying (as someone who has written a few technical books of his own)—Congratulations!

I am sure you (assuming this is your first book) are learning that this is a labor of love, and I wish you the very best in this endeavor. You should be proud!

I was exposed to "data oriented programming" thanks to Clojure—wherein maps/sets are the constructs used to pass data (as plain data) around, with simple functions that work with the data, as opposed to the traditional OO (hello ORM) that mangles data to fit some weird hierarchy.

Java's recent innovations certainly make this a lot easier, and I am glad someone is looking at propagating a much needed message.

I will take a look at the book, but I wish you the very best.

The minimum price of the book is free. You could grab a copy and determine if you like what you see and then pay the full price.

Previous discussion on HN with 108 comments—https://news.ycombinator.com/item?id=25591492

Previous submission (with 67 comments): https://news.ycombinator.com/item?id=25834444

IBM acquired RedHat who made Ansible. I believe that’s what the parent comment is alluding to.

Correct URL to windmill on GitHub

https://github.com/windmill-labs/windmill

(Or @rubenfiszel could edit their post)

> The dangerous commands are git-reset and git-checkout

Don't forget about `git-restore` which replaces `git reset -- filename`

While I'd like to think that this is _somewhat_ useful, I am a little hesitant. The issue I see with these bite-sized recipes is that there is no context, no place for nuance, and no hint that the behavior you see might be different for a variety of reasons.

Take the following for example:

> Oh shit, I need to change the message on my last commit!

> git commit --amend

It's important to realize here that if you are simply trying to edit the last commit message, you *should not* have anything in your index (that is, staged). Otherwise those changes will be recorded in the amended commit! What Git does is essentially move all the changes recorded in the commit you are amending _into_ the index, and then run `git commit -m <amended-message>` ... so if you have files in there, those will get mixed up with the ones in the commit.

Here's another one:

> Oh shit, I accidentally committed to the wrong branch!

> A lot of people have suggested using `cherry-pick` for this situation too, so take your pick on whatever one makes the most sense to you!

Umm ... No! The solution proposed (with `git reset --soft`) and a cherry-pick are NOT the same! Not even close! You will produce two completely different histories.

This final one, given when this page was written, _may be_ understandably incorrect

> Oh shit, I need to undo my changes to a file!

> `git checkout [saved hash] -- path/to/file`

There is the introduction of a new command called `git-restore` (https://git-scm.com/docs/git-restore) that (thankfully) is named more appropriately—it "restores" a file. I wrote a thread on it on Twitter, so if you are curious perhaps this will help: https://twitter.com/looselytyped/status/1501934009370042371

*Shameless plug for my book*

My book, Head First Git, was published by O'Reilly this January. I posted a submission here on HN about it https://news.ycombinator.com/item?id=30072348 so if you want any details feel free to peruse that.

Some links:

- Amazon: https://www.amazon.com/Head-First-Git-Learners-Understanding...

- O'Reilly's online platform (Needs subscription): https://learning.oreilly.com/library/view/head-first-git/978...

- Companion website: https://i-love-git.com/

(Edited for formatting)

This is off-topic, but I wanted to say a big Thank you for DataTables. I used it on many a project and still rave about how fully functional it is.

This reminds me a brilliant article [1] by Barbara Oakley, who has a _superb_ course on Coursera on "Learning How to Learn" [2].

In this article, Barbara talks about how memorization helped her with Mathematics, a subject that she had previously struggled with. In particular, this line stands out to me

> Continually focusing on understanding itself actually gets in the way.

[1] https://nautil.us/how-i-rewired-my-brain-to-become-fluent-in... [2]https://www.coursera.org/learn/learning-how-to-learn

P.S: Her book is really good too https://www.amazon.com/Mind-Numbers-Science-Flunked-Algebra/...

[Update: Apparently she wrote a book based on the course—https://www.amazon.com/Learning-How-Learn-Spending-Studying/...]

There was a discussion around Meld and other tools just yesterday here at HN: https://news.ycombinator.com/item?id=30741123

@luxpir mentioned Obsidian in another comment [1] and it might be what you are looking for, in particular with a community plugin called Obsidian Dataview [2]. Dataview uses JavaScript as a query language and can query the Obsidian "vault" and create different views.

Another tool to look at is Logseq [3], which is essentially an outliner (supports both MarkDown and Org syntax), but supports a rather simplistic TODO management system. The benefit here is exactly what you describe—as you work in Logseq, you can create Todos, thereby connecting the task to the related source and any context that surrounds the todo. Furthermore, Logseq also allows for queries [4], allowing you to query your "knowledge graph", which you can embed in other pages.

Both Obsidian and Logseq store your files locally, so they can be easily version-controlled (In fact, Logseq routines commits your files for you).

[1] https://news.ycombinator.com/item?id=30747131

[2] https://github.com/blacksmithgu/obsidian-dataview

[3] https://logseq.com/

[4] https://logseq.github.io/#/page/Queries

[Edited for formatting]

My understanding is that Github called this "pull requests" because it does something similar to the `git-request-pull` function (See https://git-scm.com/docs/git-request-pull).

I quote

> Generate a request asking your upstream project to pull changes into their tree. The request, printed to the standard output, begins with the branch description, summarizes the changes and indicates from where they can be pulled.

GitLab, on the other hand, _does_ call it "merge requests" because you to your 12-year old's point, that is what they are.

[shameless plug]

Since you asked, I just published Head First Git. I did a "Show HN" that didn't get much traction, but rather than repeating what I said there, I'll just post the link—https://news.ycombinator.com/item?id=30072348

[end shameless plug]

And to the point many others made, there are a _lot_ of resources out there, but if you are looking to start back at the basics, I feel my book (which is designed for beginners) might be a good start.

Of course there is the canonical Pro Git (https://git-scm.com/book/en/v2) book.

And once you understand the _Directed Acyclic Graph_ I feel https://github.com/git-school/visualizing-git is a great project to see what happens when you run certain operations in Git.

Perhaps you've concluded that I love Git, and I love teaching it—I am @looselytyped on Twitter (DMs are open) if you want to reach out and we can carry out a conversation elsewhere—always willing to talk Git.

Edit—I replied to the wrong comment. My apologies kqr. This was meant for VeninVidiaVicii.

If you are interested in a detailed account of the cyberarms race, check out "This Is How They Tell Me the World Ends: The Cyberweapons Arms Race" by New York Times reporter Nicole Perlroth. While the books tends to get a tad repetitive after a while, and definitely skirts many of the technicalities, its definitely provides a lot of insight into the underground zero-day exploits markets and the cyberarms race that we are in right now.

https://www.amazon.com/This-They-Tell-World-Ends/dp/16355760...

*shameless plug*

> A possible way to make things interesting is to teach the material as a story with fiction characters and a bit of drama.

I am wrapping up the final touches on my latest book, Head First Git[1][2] and I will admit that it wasn't till I was midway through the book when it _really_ dawned on me on how important this is. Some of you might be familiar with the Head First series (if you are not, Head First Design Patterns [3] is a great place to start). It uses a very conversational tone, filled with characters, and lighthearted stories to explain technical issues. Lots of drama, visuals and exercises to help cement ideas.

I took on the project because I feel like I am intimately familiar with Git. Despite that, this book is one of the hardest things I've ever done, mostly because every chapter needs a narrative, with fictional characters, conversations, and problems they are aiming to solve, all while keeping a technical topic in scope.

I know that writing this book has certainly influenced how I might teach or speak on a topic in the future, but the OP is absolutely right—engaging the reader by making the stories about "people" certainly makes the book more interesting and easier to digest.

On the flip-side, it makes the book less _dense_.

[1] https://www.amazon.com/Head-First-Git-Learners-Understanding...

[2] https://learning.oreilly.com/library/view/head-first-git/978...

[3] https://www.amazon.com/Head-First-Design-Patterns-Object-Ori...

(edited for formatting)

Neat! Quick question—your pricing says "3 forms • 100 submissions" — Is that 100 submissions a month, or once you cross a 100 you have to sign up for the subscription?

I have a use for this, so I think I will sign up regardless.

[Disclaimer: I know both Mark and Neal well. I don't think it matters here but I just wanted that out of the way]

Their follow-up book to Software Architecture Fundamentals is also available on O'Reilly - https://learning.oreilly.com/library/view/software-architect...

Yes, please! I wore the Casio F105W for over a decade, and really want someone to create this.

Your strap looks really nice. I might have to see if I can do that with my watch—I have at least 3 F105W lying around right now.

Not the author of the comment but a quick search led to this

https://github.com/sirupsen/zk

Agreed with the other recommendation of Pro Git.

If you want to learn Git from the inside out, I wrote a two-parter that aims to explain Git from the inside out, focusing on the data-structure Git uses:

https://looselytyped.com/blog/2014/08/31/gits-guts-part-i/

https://looselytyped.com/blog/2014/08/31/gits-guts-part-i/

Finally, _if_ you have an O'Reilly subscription, I am currently writing Head First Git (first four chapters are in early release). If you are not familiar with the Head First series, its a rather unique format that involves using lot of pictures to explain ideas and traditionally the books move a lot slower than most technical books. Ideas/concepts are cemented using puzzles, quizzes, crosswords.

You can see a list of the existing ones here https://www.amazon.com/Head-First-Series-Books/b?ie=UTF8&nod...

Feel free to email me if you need any more resources—I have spent a lot of time teaching Git.

Brilliant post!

This system reminds me of Bullet Journaling (https://bulletjournal.com/), which I have used on and off for a long time now. Folks who have adopted Bullet Journaling have come up with some very interesting symbols to capture parts of the day (some which I have found more useful than others).

I do find that any paper-based system breaks down for things that are recurring, and I have to resign and use some calendaring system to accommodate those (think changing the air-filter on the HVAC). I also feel that longer-than-a-day projects are harder to track on paper (If anyone has suggestions here I am all ears). I often find myself thinking of a project, breaking it down, then using paper to take one or two everyday till I feel like I am done.

My approach to finding balance between paper and electronic is

- Use paper daily (for the same reason that the OP suggest). Object permanence is real. I can't tell you how many times I just _remember_ writing something down on the left-hand side near the top that has saved my life. - If a recurring reminder comes through, add it to the list of Todos for today (on paper) - At the end of the day I usually end up transcribing my day into markdown notes (using https://bear.app/)

Over time I have learned that not everything works well in one format (I have been thinking about getting the Remarkable but my god that's steep)—What I end up doing is "linking" from one medium to another.

For example, if I start by writing an entry or a note on paper that I feel will be better described in a diagram or a code snippet I simply put a note on paper telling me to go to Bear (Since all notes are dated this is relatively easy). Or vice-versa—if I doodled out a diagram on paper, I simply put a "See notebook" in my Bear notes.

Looking forward to seeing how others are doing this.