101–110 of 318 posts
Keep on fighting the good fight, Beej.
On the promise of going back in time, I’m finding myself getting more utility of VS Codes timed snapshots than my own commits. I find it hard to judge when things are in a good enough state to commit and especially good enough to have a title. I might start writing a new function, decide that I want it to be a class only to give up the class and wanting to return to my almost complete function. Snapshot works pretty…
Stop worrying about titles and content and commit to your heart’s content.
When ready, restructure those snapshots into a coherent story you want to tell others by squashing commits and giving the remaining ones proper titles and commit messages. I use interactive rebase for that, but there are probably other ways too.
I can't help but feel that Git has completely missed the forest through the trees that you can make a 30+ part guide explaining how to use it.
Honestly, 99% of the pain of git is simply because people use it through the CLI. If you use tortoisegit or a visual tool, you don't need to worry about any of this because its self explanatory, and it becomes trivial to use Learning git like this is honestly just hampering yourself
On the promise of going back in time, I’m finding myself getting more utility of VS Codes timed snapshots than my own commits. I find it hard to judge when things are in a good enough state to commit and especially good enough to have a title. I might start writing a new function, decide that I want it to be a class only to give up the class and wanting to return to my almost complete function. Snapshot works pretty…
Work in a feature branch. Commit often. Squash away the junk commits at the end.
> ...and especially good enough to have a title.
Who needs a title? It's perfectly fine to rapid-fire commits with no comment, to create quick save points as you work. Bind to a key in your editor.
I treat commits in a private branch the same as the undo log of the text editor. No one cares about the undo log of your editor as they never see it. The same should be true of your private feature branch commits. They are squashed away never to be seen by human eyes again.
Earlier quoted context omitted.
If you do check it out and there are parts that are confusing, I'd love to hear about it.
This is partially a question and the rest is shameful confession: I had haltingly used cvs as a solo programmer, and when I was suddenly no longer a solo programmer and had to use git, everything went haywire. I am an Old and we never were taught anything about coding with other people who were also working on the same project. I have had many successful projects but never with another person. With that as a backgrou…
I remember reading the excellent Beej's Guide to Network Programming[0] and Beej's Guide to Unix IPC[1] as a teenager, which were incredibly approachable while still having depth—fantastic reads both and very influential on the programmer I ended up being. [0] https://beej.us/guide/bgnet/ [1] https://beej.us/guide/bggit/
Earlier quoted context omitted.
No. Source control is not that complicated. Git is just bad. As an existence proof: Mercurial is much better and simpler. I can teach someone who has never even heard of source control how to use Perforce in about 10 minutes. They will never shoot themselves in the foot and they will never lose work. There are certainly more advanced techniques that require additional training. But the basics are very easy. Git makes…
You're welcome to switch back to CVS or RCS at any time. You're also welcome to deal with their specific tradeoffs.
Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej
I can't help but feel that Git has completely missed the forest through the trees that you can make a 30+ part guide explaining how to use it.
My sense, bluntly, is that if people spent half the effort learning git that they do whining about it, no one would bother making a 30+ part guide just explaining stuff you could find in a man page. Commits are snapshots of a tree. They have a list of ancestors (usually, but not always, just one). Tags are named pointers to a commit that don't change. Branches are named pointers to a commit that do change. The index…
Commits are sets of files. They form a tree. A branch is a named location in this tree. The index aka staging area is a pre-commit that has no message. Workdir is just workdir, it doesn’t go in the repo unless you stage it. HEAD is whereafter commit will put new changes.
Do I understand git? Seems like yes. Let’s run a quiz then! Q? A.
How to make a branch? Git branch -a? Git checkout -b --new? Idk.
How to switch to a branch? Git switch , but not sure what happens to a non-clean workdir. Better make a copy, probably. Also make sure the branch was fetched, or you may create a local branch with the same name.
How to revert a file in a workdir to HEAD? Oh, I know that, git restore ! Earlier it was something git reset -hard, but dangerous wrt workdir if you miss a filename, so you just download it from git{hub,lab} and replace it in a workdir.
How to revert a file to what was staged? No idea.
How to return to a few commits back? Hmmm… git checkout , but then HEAD gets detached, I guess. So you can’t just commit further, you have to… idfk, honestly. Probably move main branch “pointer” to there, no idea how.
If you have b:main with some file and b:br1 with it, and b:br2 with it, and git doesn’t store patches, only files, then when you change b:main/file, then change and merge+resolve b:br1/file, then merge that into b:br2 to make it up-to-date, will these changes, when merged back to already changed b:main become conflicted? Iow, where does git keep track of 3-way diff base for back-and-forth reactualization merges? How does rebase know that? Does it? I have no idea. Better make a copy and /usr/bin/diff [—ignore-pattern] the trees afterwards to make sure the changes were correct.
As demonstrated, knowing the base abstractions doesn’t make you know how to do things in git.
I don’t even disagree, just wanted to say fuck git, I guess. Read guides or not, google or reason, you’re screwed either way.