- cross-posted to:
- technews@radiation.party
roadrunnertwice.dreamwidth.org
- cross-posted to:
- technews@radiation.party
You must log in or register to comment.
I totally disagree. Git is not hard. The way people learn git is hard. Most developers learn a couple of commands and believe they know git, but they don’t. Most teachers teach to use those commands and some more advanced commands, but this does not help to understand git. Learning commands sucks. It is like a cargo cult: you just do something similar to what others do and expect the same result, but you don’t understand how it works and why sometimes it does not do what you expect.
To understand git, you don’t need to learn commands. Commands are simple and you can always consult a man page to know how to do something if you understand how it should work. You only need to learn core concepts first, but nobody does. The reference git book is “Pro Git” and it perfectly explains how git works, but you need to start reading from the last chapter, 10 Git Internals. The concepts described there are very simple, but nobody starts learning git with them, almost nobody teaches them in the beginning of classes. That’s why git seems so hard.
Came here to say the same thing. The git book is an afternoon’s reading. It’s well worth the time - even if you think you know git.
People complain about the UX of the cli tool (perhaps rightly) but it’s honestly little different from the rest of the unix cli experience: ad hoc, arbitrary, inconsistent.
What’s important is a solid mental model and the vocabulary of primitive and compound operations built with it. How you spell it in the cli is just a thing you learn as you go.
Ahhhhh, that’s why! I should’ve know to read from the end not beginning lmao. Jokes aside, thanks for the advice I’ll try it out :)
Authors should write it in the opposite order.
I agree, the teaching is wrong. I always teach it visually. That seems to do the trick
h
In this thread - tons of smart people thinking that the tools we use to replace “make a backup of a file on a server somewhere” should require entire reference books, as if that’s normal.
Saying “it’s a graph of commits” makes no sense to a layperson. Hell the word “diff” makes no sense. Requiring training to get something right is acceptable, but “using CVS” is a tiny tiny part of the job, not the whole job. I mean, even most of the commenters on this thread are getting small things wrong (and some are handwaving it away saying “oh that small detail doesn’t matter”).
Look, git is hard. It’s learnable, but it’s hard. The concepts are medium hard to understand, and the way it does things is unique and designed for distributed, asynchronous work - which are usually hard problems to solve.
While I agree 100% with your main point,
"it’s a graph of commits” makes no sense to a layperson
You’re probably putting your standards too low. Every coder should know what a graph is, the basic concept at least. If you can understand fizzbuzz you can understand graphs too.
the word “diff” makes no sense
diff is short for difference. And that basically explains it
Saying “it’s a graph of commits” makes no sense to a layperson.
Sure, but git is aimed at programmers. Who should have learned graph theory in university. It was past of the very first course I had as an undergraduate many years ago.
Git is definitely hard though for almost all the reasons in the article, perhaps other reasons too. But not understanding what a DAG is shouldn’t be one of them, for the intended target audience.
I honestly don’t get why folks dislike rebase. I use it constantly, especially to squash commits so that my pull requests are a single commit that can be reverted easily.
It’s also kinda annoying to have a history full of “merge” commits polluting the commit messages and an entwined mix of parallel branches crossing each other at every merge all over the timeline. Rebasing makes things so much cleaner, keeping the branches separate until a proper merge is needed once the branch is ready.
I use rebase when I’m working in a dev branch. If someone else has pushed changes to the main branch, rebasing the dev branch on top of main is a way to do the hard work of resolving merge conflicts up front. Then I can rerun tests and make sure everything still works with changes from the main branch. And finally, when it is time to merge my dev branch to main, it’s a simple fast-forward.
Because rebase is fraught with peril, if you also push rebased branches upstream and someone else works off that branch.
If you stick to the rule of only using rebase on local branches that have never been pushed upstream, it’s an awesome tool. If you don’t, you’re eventually going to cause someone to have a bad day.
Yeah, basically anything that rewrites already pushed history and is then (force-) push is bound to create problems (unless it’s a solo dev only ever coding on a single device, who uses the remote repo as a mere backup solution).
Yep. I work exclusively in forks, and all my work is done on my machine, rebased, squashed and then pushed to my fork for a PR. No commits from main are ever touched in my rebase. It’s such a clean workflow for me.
deleted by creator
deleted by creator
A much simpler solution: don’t use the git CLI. And in my professional life I don’t know a single person who does. The shortcomings of git have long been abstracted away and as problematic as the CLI is, it’s now just an internal library of the tools we actually use.
Also the
git pullcriticism is weird. Yeah it exists on paper, and year every so often once in a blue moon there’s a conflict after a pull with rebase, but… this doesn’t even begin to dent the oodles of time saved from just doing Ctrl+T in IntelliJ and be up-to-date with no further input. Why waste 20 minutes 40x-100x a day instead of 45 minutes once every 3-6 months? Especially this case:My favorite version of this is when the novice has followed someone’s dodgy advice to set pull.rebase = true, then they pull a shared branch that they’re collaborating on, into which their coworker has just merged origin/main. Instant Sorcerer’s Apprentice-scale chaos!
I’m sorry, but are you collaborating or competing on a shared branch? If it is a collaborative effort, maybe just talk about it? And in fact, unless the other person is an utter asshole, they’ll have done so before merging in the new changes from
main. That’s not even to mention that in 99,95% of cases or so, that exact scenario is perfectly fine and gets resolved without any issues whats-o-ever and no user input necessary. Bringing us once again to the situation where you save a moderate amount of time multiple times a day by always just pulling.(edit)
Don’t get me wrong, all of this criticism is of course valid. But it feels like a very arcane case, as no project should be able to produce the issues frequently unless there’s some underlying problem in either the mode of collaboration or the structure of the project in the first place, and the usage of git is long abstracted away and the tools handle virtually any and all edge case, including making merging far smarter than if you were to use the CLI.I’ve used the git cli exclusively for more than a decade, professionally. I guess it varies wildly by team, but CLIs are the only unambiguous way to communicate instructions, both for humans and computers. That being said, I still don’t mess around with rebase for anything, and I do use a gui diff tool for merge conflict resolution. Practically everything you need to do with git can be done with like 10 commands (I’m actually being generous here, including reset, stash, and tag).
That being said, I still don’t mess around with rebase for anything
Rebasing has a worse reputation than it deserves. It’s something you just get used to - just like how git use is, when you started using it. There are a couple of strategies to make it easier and less anxiety inducing:
- Before starting a rebase of a long branch, create a new branch. That way in case you seriously mess up, you can just delete the rebasing branch and rename the old branch to restore everything (you can usually get away with rebase abort. This is just added safety). Even in case of a successful rebasing, you can just keep the backup branch around, as a faithful record of actual development history.
- Do only one (or max 2) operations in a single rebases. Do this over multiple rebases to get what you want.
After a while, rebasing becomes as simple as commit or merging.
Rebasing and merge conflicts are the top ways that git can turn into a mess. I know that rebasing could (in some circumstances) make merge conflicts less of an issue, but I just mostly think the value of “commit grooming” is overrated. I don’t want to argue about this, if you like doing it, go ahead.
I had to check and make sure I didn’t type the comment above because it sounds exactly like me.
All UIs do things slightly differently, the CLI is always exactly the same… Everywhere. UI for non trivial conflict resolution? Definitely. For everything else, CLI.
And, I’m also reticent to use rebase unless I have to. Gimme that good ole FF :)
UI for non trivial conflict resolution? Definitely.
I dont know about that… Never found they help that much in conflict resolution. They give you some nice buttons for accept their or accept our changes but really I find more often than not those are what breaks code as you often want a mash-up of both sides - which needs to be manually done even in UIs.
Otherwise it is just find the marked sections in the file, and make it look like what you want it to after the merge/rebase. And that is the hardest part - figuring out what it should look like. Which is made easier if you only ever have small commits and merge back to master frequently minimizing the amount your branches drift from each other.
don’t use the git cli. In my professional life I don’t know a single person who does
I do, I find it much simpler than using the GUIs
I usually use a gui but I know plenty of colleagues who exclusively use cli. I’ve never understood if it’s an ego thing or what but it’s an incredibly popular way to use git
I exclusively use CLI, it’s not ego at all, I simply find typing what I want to be quicker than clicking buttons. I’ve written a bunch of aliases to automate my common workflows.
When I need to help a colleague who’s made a mess of something, I can easily give them the command to fix it rather than finding the right options in their GUI of choice and it’s often because of some broken abstraction in the GUI they got into the mess in the first place.
Yeah there are totally commands I use daily, but the visualization involved in looking at the log and available branches (which is a constant use case) is much easier in a gui for me. In fact I’d go as far as saying logs, diffs, and branching in cli are neigh unusable. The buttons I click while in the gui (like fetch/pull/commit) are largely used because at that point (after finding and checking out the right branch, etc) it would be slower to switch back to cli.
I only mentioned ego because I’ve seen multiple junior devs struggling with the command line resist using a gui even when it solves a specific problem they are having quite easily. To each their own though.
I use the CLI for simple commands, especially if helping someone on another PC and I don’t have access to my preferred tool, but I honestly don’t get people who use it religiously and never even try tools with GUIs. The convenience of being able to easily see the commit history, scroll through it, have a right click context menu or ability to just click it and see file changes (and then right click those files for additional options), is just something I can’t abandon. Nowadays even the aliasing can be replicated in those tools if they support creation of custom commands so even that is a moot point - with some setup you can be as fast as with a CLI.
Meh I find I can do 95% of what I need through the cli just fine. Diff-ing can be annoying if you just want to skim through a commit but otherwise I don’t see what I miss by using the cli
Exactly my same thoughts!
I do have a huge ego, but I’ll claim it’s a total coincidence that I use CLI git.
My main reason to use mostly CLI is the better error messages I get when something goes wrong.
My secondary reason is that my preferred GUI tools for git didn’t used to have support for operations I do often such as ‘cherry-pick’ and ‘rebase’. I think that is mostly solved now, but my habits change slow and I’m used to the CLI.
Haha fair. My experience though, is that cherry picking is easily done in gui and I’ve honestly never attempted on cli because it only takes me three clicks in Fork
Yeah. Cherry pick was the killer feature for CLI back when I was forming habits. Seems like it’s built into most tools now, which is really nice.
There are things that my GUI of choice lack, so I occasionally type out a command, although I did also bind a couple of commands to GUI buttons, so there’s that.
Which to me is just wild unless you’re doing something you wouldn’t want to use an IDE for - and that’s not actually that many professional things, if I’m being honest. But if you use an IDE, then it’s far easier, faster and importantly doesn’t take you out of your mental flow to just use the built-in git abstraction of that IDE.
O that’s my pet peeve, I hate integrated git GUI’s in IDE’s. The only useful thing is file and code highlight for changes, other than that I disable that stuff as fast as possible.
I mostly agree. The caveat to this is I’ve had to learn CLI for programmatic use cases like automation.
I might be suffering from stockholms syndrome here, but my prefered ways of working with git are the cli and the fugitive vim plugin which is a fairly thin wrapper around the cli. It does take a middle ground approach on hiding the magic and forcing you to learn the magic which I suppose can be confusing for beginners when you work collaboratory and something happens that forces you to go beyond pull/add/commit/push
In my (admittedly limited) experience, mercurial is much more intuitive than git. I really dislike that git branches are only tags on the heads and completely ephemeral. It favours creating a single clean history instead of preserving what actually happened.
I only stick with these:
- pull
- add
- commit
- push
Easy.
Merge is love merge is life, get the hell out of here with that rebase witchcraft.
Excellent article
Personally it was when I was trying to commit and I got stuck in an authentication loop of git asking for my username or email (even used --global) and it would not work or remember no matter what I tried (was recommended to reinstall mint, yeah no lmao not again).
Ended up installing the unofficial GUI and I’m MUCH happier but I tell ya if you bork something in Mint it’s really hard to fix it if your not a CLI wizard.
Git GUI wise I can do all the basic stuff I need and if something breaks than I use the CLI because there’s more documentation on it
deleted by creator
