61–70 of 147 posts
Earlier quoted context omitted.
These articles aren't for the Artisan - they are for, in your metaphor, the apprentice and journeyman. You should do a lot of learning on using a table saw before you touch one. Using git wrong won't kill you, using a table saw wrong will.
Messing up a rebase and then force pushing your altered history might at least equate to shaving off a small chunk of finger :-)
There's an article like this every week or so.. I don't get it. Git isn't that hard.. You can pretty much get by 99% of use cases with like four or five commands.
Quick quiz: What does 'git checkout a/b' do? I've seen users end up with 3 different meanings.
Earlier quoted context omitted.
My thoughts exactly. Maybe it's because I've used SVM and Mercurial before but I learned Git very easily. I find the commands and options fairly intuitive once you know you're manipulating a graph of patches. But I guess this is very subjective. After all, I've never been able to master gnupg despite how long I've been using it for.
> I find the commands and options fairly intuitive once you know you're manipulating a graph of patches. On the contrary, I find the "graph of patchs/Merkel tree/whatever" model pretty easy to understand, and have difficulty in using the commands to make the tree look like how I want it to.
There's an article like this every week or so.. I don't get it. Git isn't that hard.. You can pretty much get by 99% of use cases with like four or five commands.
The proliferation of articles like this is a very very good indication, that, yes, git is that hard, especially if you have to collaborate with other people. Everyone has a different idea of what git does, what things are called, and different interpretations of the vast git vocabulary. What is a rebase? What is a branch? What is a reset? People have different mental models for all of these things. Git would be easie…
There's an article like this every week or so.. I don't get it. Git isn't that hard.. You can pretty much get by 99% of use cases with like four or five commands.
I had a coworker explain that he did a merge and something unexpected happened to his branch. I had to explain to him that what happened was totally expected and that his understanding was what was wrong.
Earlier quoted context omitted.
On debian this is the default behavior.
Same in Ubuntu. Bash completion on Ubuntu/debian is out of this world. I can do things like lxc exec and get a list of currently running containers.
There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…
On the other hand, I don't know who these articles are really for. I have _never_ met a developer who struggles with git. Not many claim to understand it deeply, but all can rebase, cherry-pick, use the reflog, etc. and almost never do they run into issues. It mystifies me. Git isn't hard, nor complicated. "Checkout" has a few too many meanings, and thats the singular gripe I have with it.
There's an article like this every week or so.. I don't get it. Git isn't that hard.. You can pretty much get by 99% of use cases with like four or five commands.
The proliferation of articles like this is a very very good indication, that, yes, git is that hard, especially if you have to collaborate with other people. Everyone has a different idea of what git does, what things are called, and different interpretations of the vast git vocabulary. What is a rebase? What is a branch? What is a reset? People have different mental models for all of these things. Git would be easie…
Reading just enough of the git-scm book to get a basic mental model of staging, branches, and pushing/pulling from a single remote (aka the things new people actually probably trying to do with git) can serve you well enough. I've since worked on teams that expected WIP commits to be squashed, used multiple remote repos, etc, but the above should be all the git most of the people complaining about git actually need.
git remote add origin git@yabbadabbadoo:org/team
git checkout -b feat/my-work-branch
# do work
git add -p .
git reset HEAD accidental-file.txt
git commit -m "Add sweet feature"
git push -u origin feat/my-work-branch
git pull origin feat/my-work-branch
1. People tend to mess up with a tool more often when they are still getting acquainted with it. When things get hairy, people tend to just try random fixes so they can get back to work which makes the problem hairier still.
2. git might be one of the first tools someone uses that expects end users to map their mental model to it rather than trying to fit their pre-existing mental model.
There's an article like this every week or so.. I don't get it. Git isn't that hard.. You can pretty much get by 99% of use cases with like four or five commands.
It's not hard but the UX is horrible.