301–310 of 550 posts
Earlier quoted context omitted.
> First of all, using "noob" like that is offensive. Everyone's a "noob" at some point. And if that's how you talk and treat people, I probably wouldn't want your help. Unfortunately, a word needs to exist that stands in for this: "Person, who isn't so different than myself when I started, with little experience who is mistake prone due to the lack of experience, who's mistakes creates disruption and often great expe…
Newbie is a nicer word.
It is ironic that Linus hates C++ so much, and then proceeds to create what is for all practical purposes, the C++ of source control systems.
What would you recommend using instead of git? (Myself, I've been heard complaining that git is overly complex, but the source code control systems that I used to use before git include Subversion, CVS and various Rational products and I have no desire to go back to any of them.)
I catch up on a forum a few times a year, asking myself if it's ready for me to switch a repo or two over and see how it goes. So far I have to answer no, but I'm hoping it's just a matter of time.
It is unfortunate that: + git switch is documented as "EXPERIMENTAL" + git --help lists git switch but not git checkout as an important command This is a documentation inconsistency. It can't be both the canonical interface to use and experimental at the same time.
When you checkout a specific commit and are now in detached HEAD state, you are by default given the message
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c
Or undo this operation with:
git switch -It is ironic that Linus hates C++ so much, and then proceeds to create what is for all practical purposes, the C++ of source control systems.
He was "scratching his own itch" (see http://www.catb.org/esr/writings/homesteading/cathedral-baza... ). Git was written to meet the version control requirements of the Linux kernel. It works well for that project's needs which are an outlier for most development needs unless you are working at FAANG scale.
Earlier quoted context omitted.
> My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use or not. Imagine having 100 complex things bouncing around your head and having to make that 101 when you forget the order of arguments to merge. Imagine if you knew a cabinet builder who said: "My job isn't to use a table saw, it's to build beautiful cabinets. If I get…
A more apt comparison would be to using a saw vs using a saw with gloves on. With gloves it's safer and more comfortable, but you're not quite as in touch with the wood as you would be without one. Without gloves you feel badass because you don't care about safety, and you might be able to carve out some slightly more intricate things. Either way the outcome is roughly the same and it really doesn't matter what your…
DO NOT use gloves with a table saw, jointer, etc
There are exceptions, but if you want a simple rule: DO NOT use gloves with power tools
It is extremely dangerous. You can take an injury that would've been a nick on the finger and turn it into a lost hand.
A lot of comments along the lines of ‘why do people use instead of learning the commands’. For me, I used to use the terminal git, and I still do occasionally. But I use Sourcetree now for most things because I make less mistakes seeing the tree visually all the time. My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use or…
We are all using git only because Linus wrote it. The cargo cult is real and very much alive in our industry, I think precisely because we are all here to write specialist software. Too busy in our domain to worry about version control nuances so we just go with what is popular and don't think about it too much. It's not just version control, it's libraries, frameworks, languages, all of it. If it's not popular it's…
It's much better than Subversion that was the standard before git arrived.
And it's much better than Mercurial that was competing to become the source control system to replace SVN.
Earlier quoted context omitted.
The irony with git is that the underlying data model is far simpler than the user interface implies. People assume git is complicated because the user interface is complicated, but it really is very simple under the hood. So much so that you can write your own basic version of git in a couple of hours: https://wyag.thb.lt/
The problem is that git leaks the underlying data model all over the place, even where it's unnecessary to actually controlling versions. It's a nice data model, but the user view shouldn't expose it. The data model is an implementation detail, but git treats it like a show & tell.
As a helpful aside, in my experience, there are only about a dozen or so Git commands you need to do ninety percent of your work. You don't need to become a git zen master right away. 1. git init: to start a new repository 2. git status: checks your current state 3. git add -A: To begin tracking files 4. git commit -am: Commit all changes in the working directory with a message added on 5. git switch -c [branch name]…
I'm mildly amused that your set of commands can't actually commit anything other than a brand-new file! I will admit that I'm a lazy git user, and do most of my commits with `git commit -a`, rather than `-am` since I do try and give a short paragraph explaining the reasoning behind whatever the title message claims is the purpose of the commit. I do run `git diff` first to see what I've changed, and if the diff has u…
Earlier quoted context omitted.
This is exactly what motivated me to write Learn Git The Hard Way - I was surrounded by people who depended utterly on IDEs and got themselves into terrible states that based on models that were refractions of what the the (universally available) CLI gives you. The best example of this was when I worked with a project with 12 dev teams that didn't rebase. They asked me where a commit came from, and when I ran 'git lo…
Any developer demonstrating that level of daily incompetence with their basic tools of the trade should never be allowed to write code. The fact that this level of incompetence seems the rule rather than the exception speaks to the rather terrifyingly pathetic state of software, where badly engineered systems end up killing people. Source: firmware engineering consultant that cleans up messes like these for some of t…