6 ms·

Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej

by beej71 2y ago

fabiensanglard 2y ago
Loved your Network programming guide :) !
1propionyl 2y ago
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!
junebash 2y ago
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!
- beej71 2y ago
  You're welcome! :)
alberth 2y ago
I really appreciate you offering the content as a single page. Thanks for all your guides over the years. Truly invaluable.
bassp 2y ago
Your network programming guide really saved my bacon back when I was taking a networking class, I appreciate all your hard work!
iamthejuan 2y ago
I am just happy and thankful that people like you exists.
JetSetIlly 2y ago
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!
unstuck3958 2y ago
I read your guide to C programming as a teen, and as a firmware dev today I'm forever indebted to you.
- pizzalife 2y ago
  Same!
aidos 2y ago
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.
- usrme 2y ago
  This is a fantastic mention! I've been commenting out my commit message lines and then saving as a way to trigger this. Feeling like a caveman...
  - celticninja 2y ago
    Guilty as changed your honour
    - malvim 2y ago
      Guilty as UNchanged*
- dotancohen 2y ago
  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.
- ericholscher 2y ago
  I usually use :q! which seems to do the same thing
  - alexjm 2y ago
    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.
danw1979 2y ago
Thank you for this Beej! 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…
tvaughan 2y ago
Doing Chico proud!
ZoomZoomZoom 2y ago
There's an issue for the IPC guide on GitHub that's almost a year old with zero reaction.
- beej71 2y ago
  That's my lowest traction guide, I think, not counting Beej's Guide to Killing Dragons. :) I've fixed it, and wrote a quick script to list all issues and PRs on all my books so they don't fall through the cracks.
  - ZoomZoomZoom 2y ago
    Thanks!
VierScar 2y ago
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
kali_00 2y ago
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!
jdmoreira 2y ago
Beej you are a legend. We all love you! You were a beacon of light for us in the 90s
xbar 2y ago
Thank you. I will be forever grateful for your work and its improvements of my life.
patchd 2y ago
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.
- beej71 2y ago
  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. I'll mull it over. :) Cheers!
woodrowbarlow 2y ago
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. :)
greyw 2y ago
Thanks for your great guides. Helped me a lot during my career (so far) :)
criddell 2y ago
What's the difference between the one- and two-sided pdfs?
- blacksmith_tb 2y ago
  Layout for printing (on paper, for those who still do that) I presume.
  - beej71 2y ago
    Exactly this. There are three main differences: 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.
chanux 2y ago
Thank you legend! ස්තුතියි
inlart 2y ago
Great guide. Figure 6.1, 6.2 and 6.3 are missing commit “6”.
manaskarekar 2y ago
First followed you on flickr ages ago, then your networking guide! Thanks for the amazing resources.
yrotslluf 2y ago
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. "rerere" (https://git-scm.com/book/en/v2/Git-Tools-Rerere https://git-scm.com/book/en/v2/Git-Tools-Rerere) will allow git to "reuse recorded resolution" so that you don't have to do them manually each time. My gitconfig for these: [alias] forked = "!f() { git merge-base $1 --fork-point; }; f" squash-first = "!f() { git rebase -i `git merge-base $1 --fork-point`; }; f" [rerere] enabled = true
fphilipe 2y ago
Not wrong, but one thing I did not spot in all the great explanations related to HEAD is that @ is an alias for HEAD that is a lot easier to type.
- beej71 2y ago
  I wouldn't have put it there because I didn't know that. What the hell... LOL Now that's a hilarous thing to get through a book not knowing.
defanor 2y ago
In section 5.7: > 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".
- beej71 2y ago
  D'oh! Fixed.
frogsRnice 2y ago
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
raju 2y ago
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-forward-merges.html#branches-and-fast-forward-merges 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/bc204b742735ae06f65bb20291c95985c9633b7f/refs.c#L665-L668 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.
- beej71 2y ago
  Hrm. I didn't realize. I unset `init.defaultbranch` and it uses `master` and prints a block of hints. > hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and 'development'. The just-created branch can be renamed via this command: That's going to make it more "interesting" to write the fix, that's for sure. Thanks!
chr86 2y ago
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. Just a suggestion
- beej71 2y ago
  Yeah, I was speaking a little fast and loose here since this was just the intro part. I was worried that it would actually be more confusing to say that we merged them and they pointed to different places... which is of course what actually happens. Let me see if I can do that and save the clarity.
chr86 2y ago
Ok, so unless I'm missing something, this is a big error. In 9.4 there's no way reallinux/master points to same commit as master after the merge. It will still be where it was, one commit behind.
- beej71 2y ago
  Yeah... so re-reading that, I don't know what I was thinking. Uploading a rewrite of that bad crap now.

Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej

by beej71 2y ago

Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej

fabiensanglard 2y ago

Loved your Network programming guide :) !

1propionyl 2y ago

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!

junebash 2y ago

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!

beej71 2y ago
You're welcome! :)

alberth 2y ago

I really appreciate you offering the content as a single page. Thanks for all your guides over the years. Truly invaluable.

bassp 2y ago

Your network programming guide really saved my bacon back when I was taking a networking class, I appreciate all your hard work!

iamthejuan 2y ago

I am just happy and thankful that people like you exists.

JetSetIlly 2y ago

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!

unstuck3958 2y ago

I read your guide to C programming as a teen, and as a firmware dev today I'm forever indebted to you.

pizzalife 2y ago
Same!

aidos 2y ago

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.

usrme 2y ago
This is a fantastic mention! I've been commenting out my commit message lines and then saving as a way to trigger this. Feeling like a caveman...
- celticninja 2y ago
  Guilty as changed your honour
  - malvim 2y ago
    Guilty as UNchanged*
dotancohen 2y ago
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.
ericholscher 2y ago
I usually use :q! which seems to do the same thing
- alexjm 2y ago
  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.

danw1979 2y ago

Thank you for this Beej! 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…

tvaughan 2y ago

Doing Chico proud!

ZoomZoomZoom 2y ago

There's an issue for the IPC guide on GitHub that's almost a year old with zero reaction.

beej71 2y ago
That's my lowest traction guide, I think, not counting Beej's Guide to Killing Dragons. :) I've fixed it, and wrote a quick script to list all issues and PRs on all my books so they don't fall through the cracks.
- ZoomZoomZoom 2y ago
  Thanks!

VierScar 2y ago

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

kali_00 2y ago

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!

jdmoreira 2y ago

Beej you are a legend. We all love you! You were a beacon of light for us in the 90s

xbar 2y ago

Thank you. I will be forever grateful for your work and its improvements of my life.

patchd 2y ago

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.

beej71 2y ago
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. I'll mull it over. :) Cheers!

woodrowbarlow 2y ago

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. :)

greyw 2y ago

Thanks for your great guides. Helped me a lot during my career (so far) :)

criddell 2y ago

What's the difference between the one- and two-sided pdfs?

blacksmith_tb 2y ago
Layout for printing (on paper, for those who still do that) I presume.
- beej71 2y ago
  Exactly this. There are three main differences: 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.

chanux 2y ago

Thank you legend! ස්තුතියි

inlart 2y ago

Great guide. Figure 6.1, 6.2 and 6.3 are missing commit “6”.

manaskarekar 2y ago

First followed you on flickr ages ago, then your networking guide! Thanks for the amazing resources.

yrotslluf 2y ago

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. "rerere" (https://git-scm.com/book/en/v2/Git-Tools-Rerere https://git-scm.com/book/en/v2/Git-Tools-Rerere) will allow git to "reuse recorded resolution" so that you don't have to do them manually each time. My gitconfig for these: [alias] forked = "!f() { git merge-base $1 --fork-point; }; f" squash-first = "!f() { git rebase -i `git merge-base $1 --fork-point`; }; f" [rerere] enabled = true

fphilipe 2y ago

Not wrong, but one thing I did not spot in all the great explanations related to HEAD is that @ is an alias for HEAD that is a lot easier to type.

beej71 2y ago
I wouldn't have put it there because I didn't know that. What the hell... LOL Now that's a hilarous thing to get through a book not knowing.

defanor 2y ago

In section 5.7: > 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".

beej71 2y ago
D'oh! Fixed.

frogsRnice 2y ago

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

raju 2y ago

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-forward-merges.html#branches-and-fast-forward-merges 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/bc204b742735ae06f65bb20291c95985c9633b7f/refs.c#L665-L668 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.

beej71 2y ago
Hrm. I didn't realize. I unset `init.defaultbranch` and it uses `master` and prints a block of hints. > hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and 'development'. The just-created branch can be renamed via this command: That's going to make it more "interesting" to write the fix, that's for sure. Thanks!

chr86 2y ago

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. Just a suggestion

beej71 2y ago
Yeah, I was speaking a little fast and loose here since this was just the intro part. I was worried that it would actually be more confusing to say that we merged them and they pointed to different places... which is of course what actually happens. Let me see if I can do that and save the clarity.

chr86 2y ago

Ok, so unless I'm missing something, this is a big error. In 9.4 there's no way reallinux/master points to same commit as master after the merge. It will still be where it was, one commit behind.

beej71 2y ago
Yeah... so re-reading that, I don't know what I was thinking. Uploading a rewrite of that bad crap now.