81–90 of 147 posts
According to git-bisect(1), "the script should exit with code 0 if the current source code is good, and exit with a code between 1 and 127 (inclusive), except 125, if the current source code is bad."
Earlier quoted context omitted.
I got a lot of mileage out of git with "do work on my own individual branch, never use `--force anything` even if a blog post on the internet says to, and don't rewrite history." 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 work…
Specifying the remote and branch name again when doing a `git pull` is not necessary after you've set it as the upstream branch (which the `-u` option in `git push` did in your example).
"The most basic usage is: git reset useful_func.clj This will replace the useful_func.clj in the current working directory with the last committed version in the repository HEAD."
Not a good start. What it actually does is reset the path "useful_func.clj" in the index (AKA staging area) to the HEAD state. It doesn't touch the working directory.
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…
The regular people lose two days of work trying to rebase their merge commits to appease those folks.
Rebase should never have become part of the day to day git toolbox. If it didn't exist nobody would ever see a linear history, and so would never think to care about it.
Thank the maker for github's "squash merge" and "rebase and merge" buttons, which handle all that crap for you. If you're not using a tool that does that for you I'm sad for you.
The very first factual claim in the article is wrong: "The most basic usage is: git reset useful_func.clj This will replace the useful_func.clj in the current working directory with the last committed version in the repository HEAD." Not a good start. What it actually does is reset the path "useful_func.clj" in the index (AKA staging area) to the HEAD state. It doesn't touch the working directory.
You don’t have to be a genius to use git, I’ve never experienced anything like this, even though I’ve worked in 15-20 member teams with lots of conflict and all that. Read the docs and use it as it is suggested. I don’t think it is that hard... I feel like this scenario is just not from real life
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…
Then you wouldn't really need distributed source control, would you ;)
Earlier quoted context omitted.
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.
Fun fact: Ubuntu is a derivative of Debian!