181–190 of 273 posts
Earlier quoted context omitted.
Right, doing a search through the git mailing list for the use of the word "porcelain" is fascinating. It's unfortunate some of those "porcelain" projects never finished.
... because none of the power users used them.
This is nice, but I'd like a 201-level handholding on git. I've been using it for 5 years and I'm still just a clone/commit/merge/(bang head)/push user yet I know there is tons more it can do that would probably make me more effective. (I'd also like to switch my team of SVN. Someday....)
Once you have the better understanding of the graph, it's hard to find resources on how to improve from there; most resources focus on beginner stuff, or function more as a technical reference without really talking about use-cases. I've found following Mark Dominus' blog[2] for his posts about Git to be the single best thing to "level up" my Git usage once already being at a high-level.
[1]: At the time, I had to pay money for the eBook, now they have the whole thing on GitHub: https://github.com/pluralsight/git-internals-pdf
Earlier quoted context omitted.
> WHY there is a staging area I understand your second point, but I have a hard time understanding the difficulty with this part. Why is it hard for people to understand the idea of staging? You put things in a box one at a time before closing the box. Does it require more explanation than that? What do people find difficult about it?
Yes, it requires more explanation than that. I've used git for years, and never really understood why staging is even a thing. Your example is an implementation of the box-putting algorithm, but it doesn't need to be mirrored in the put-box CLI. put-close-box file1 file2 This command could encompass all the putting and closing. Since you only close boxes when you are done putting things in it, I don't see a need or p…
Anyway, `git commit file1 file2` by itself is most of the way to being the put-close-box function you want; it just doesn't work for adding/deleting files from the repo. Seems like they could make a lot of people happy by closing that gap and letting `git add` be an intermediate-level feature.
Earlier quoted context omitted.
This is like teaching people to drive a car with an automatic gearbox.
Which happens to be the only option on future car driving technologies.
Yes, once electric cars (with superior traction and brake control) take over automatic gearboxes (actually electrics don't even have gearboxes) will be the norm, but as long as there are engines driven on dinosaur fuel there will be a need for manual gearboxes. Which is why you should learn how to drive one. Once you're able to do that, driving an automatic is trivial, which was the point I was trying to illustrate.
Earlier quoted context omitted.
This is so so fitting, and describe me to a "T" as well. I'd add oh-crap-I-screwed-up-so-let's-clone-the-repo-and-start-over to the list.
What can you screw up that requires re-cloning the repo rather than just a reset --hard?
Humbly, I'd disagree that's the best, though this is a superb _part_ of the picture to teach Git well. These are nearly the last steps, I would say. When new colleagues joined our firm and hadn't yet learned Git, the problems were always the same: uncertainty. They didn't know which Git operations were safe, and they didn't understand how to perform seemingly risky maneuvers with zero risk. They're used to even more…
> So the way I would teach Git is to honestly start with the graph. Show it in action with pictures. Show how to always keep references to commits around to ensure work sticks around. Show how branching and stashing work, let them be confident that the tool will keep everything right where you left it. Personally, I think this should be coupled with teaching `git reflog` as the universal undo (as long as they don't `…
And here is something to take the garbage quality of Git manpages with some humor https://git-man-page-generator.lokaltog.net/ "git-eliminate-head eliminates all downstream heads for a few forward-ported non-counted downstream indices, and you must log a few histories and run git-pioneer-object --pose-file instead. [...]"
And here is something to take the garbage quality of Git manpages with some humor https://git-man-page-generator.lokaltog.net/ "git-eliminate-head eliminates all downstream heads for a few forward-ported non-counted downstream indices, and you must log a few histories and run git-pioneer-object --pose-file instead. [...]"
Earlier quoted context omitted.
`git log` on its own (with no flags) isn't that useful, as it's missing a lot of important information. I prefer `git config --global alias.lg "log --color --graph --oneline --decorate"`. Then you can just type `git lg` and get a much more useful overview of the state of your current branch.
git config --global alias.lg "log --color --graph --oneline --decorate" for easy copy-pasting. HN doesn't support backticks or triple backticks like a lot of markdown parsers. To get fixed-width fonts, you have to insert 4 paces at the beginning of the 'code' block.
Of course four will work, it just adds more indentation.
I think the best thing you could do for novices is to avoid priming them with preconceptions of Git being difficult. Psyching people up before instructing them never seems to do people any good, yet it's very common.
The last thing you want to do is turn them off entirely, or gatekeep the profession to exclude people who aren't good at reading dense documentation.
The best way to teach git is to get them comfortable with "Add, Commit, and Push" and then explain what's happening at each stage.