Not wrong, but since you’re mentioning vim in the context of git, might be worth adding :cq as a way to exit with a non-zero status to prevent git from finishing the commit / operation.
The minor difference is that :q! quits without saving but returns zero as the exit code, but :cq quits with a nonzero exit code. Git interprets the nonzero exit code as "editing failed", following the Unix convention that zero means success. If you didn't save the commit message while working on it, :q! will send the empty template back to Git, which Git is smart enough to not commit. But if you accidentally save your work partway through, :q! will still commit the message you wanted to abandon.
That only works if the edit buffer is blank or only has commented out lines. In other cases, such as when you're trying to cancel a `git commit --amend` that loads up the last commit message in your buffer, :q! will not cancel the commit, but :cq will.
I just love nuggets like this. I've been using VIM for 26 years and git for about 15. I never knew about adding c. I've always felt that :q! should exit with a non-zero status code, at least if no :w had been made.
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.
> 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>`)
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.
Just a quick shout-out; I was one of the many many students you taught at Lambda School, and just wanted to say your instruction was one of the highlights of my time there. Thanks for doing what you do!
Not wrong, but worth mentioning. I really found git worktrees to be crucial to my workflow and have heard very few people mention them or even know they exist. Excellent way to keep your branches from getting their streams crossed without the headache of dealing with stashes.
I was on the fence about this one. Yes, it's totally useful, but I swore after writing my comprehensive C guide I would never write a comprehensive guide again. :) So I try to decide where to cut people loose to use other resources once they have the foundation.
All that said, they are really useful. And, honestly, the chapter would be pretty short to get basic usage down... but also if you've gotten as far as grokking how branches work, it's pretty easy to pick up worktrees. The fact that lots of people don't know they exist is points for adding it just for that reason alone.
Actual Beej? Wow I remember absolutely loving reading your networking guide. It taught me so much and really showed me the depths and breadths of what can be done in code, how the net works (pun unintended), it was a great experience for me as a kid. Thanks! <3
I found your networking guide as a kid with only some scripting experience, and it served to get me into C programming in general, so I have a special fondness for it.
Appreciate the work! Neat to see you still writing pieces like this all these years later!
Hey great work beej! I've read pro git and your guide is very good.
So in figure 5.4 you say we merge 2 commits into a new one and somehow both branches point to new commit. This will definitely confuse people new to git.
I'd say it's better to write we merge anotherBranch into someBranch and leave the former where it is. Same for the next merge.
Not wrong of course — thank you for your amazing guides! But feedback re: "15.7 Multiple Conflicts in the Rebase":
There are two things I suggest as workflows for people when I teach them about rebase workflows.
> Since rebase “replays” your commits onto the new base one at a time, each replay is a merge conflict opportunity. This means that as you rebase, you might have to resolve multiple conflicts one after another. ... This is why you can conclude a merge with a simple commit, but ...
For multiple conflicts on several commits being replayed, if it's _not_ useful to go through them all one at a time, I suggest that people do a squash first rebase from the fork point (which by definition can not have conflicts) to collapse their commits into a single commit first, and then rebase again from the branch.
For instance, if forked from main:
git rebase -i `git merge-base main --fork-point`
Squash all of those, and then as usual:
git rebase -i main
Second, when rebasing repeatedly onto an evolving branch over time, you'll often find yourself resolving the same merge conflicts over and over again.
Unrelated; I just wanted to say that I learned programming from your socket tutorials when I was a kid. Everything was so well written that I used it from highschool, to varsity to my day2day job.
Without your tutorials I’m not even sure if I would have chosen the carreer I did- thank you for all the love and effort you put into your posts; Im sure that there are many other people who you’ve touched in a similar way
Beej, your Guide to Network Programming helped me through my early UNIX career. In fact, your guide was so influential to so many people, it very quickly became recommended reading in my university's network course.
I'm delighted to see that you're still active and still producing guides. Well done!
> But in this section we’re going to be talking about a specific kind of merge: the fast-forward. This occurs when the branch you’re merging from is a direct ancestor of the branch you’re merging into.
Looks like "from" and "into" are swapped: "main" is "into" there, "newbranch" is "from", and "main" is a direct ancestor of "newbranch".
Along with many others here, your network programming guide helped me so much back in the early days of my education and career. So thanks for that too…
joining the crowd to say thank you. i've been using your materials for over a decade.
in my experience, strong writing and communication skills are one of the best ways to stand out as an engineer -- and your articles are maybe the best example of this out there. keep on setting a great example for us. :)
1. The margins are offset in two-sided, alternating pages.
2. The page numbers are justified alternately left and right in two-sided, and the page header differs left and right.
3. Sometimes a blank page is injected with two-sided to make a chapter start on the correct side of the book.
Not wrong, but something I found confusing, in section 2.7.5 (page 11 of PDF):
"Let's say you modified foo.txt but didn't add it. You could: <git command>"
Followed by:
"And that would add it and make the commit. You can only do this with files you added before."
Wait, what? So, I modified foo.txt but didn't add it, and then the command to add and commit at the same time can only be done with files I did add before?
Guide was working great to heal years of git trauma up until that point though!
Love, Beej