Hacker News new | past | comments | ask | show | jobs | submit login

A lot of comments along the lines of ‘why do people use <ide> 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 <ide> 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.

The guy who knows every command of git backwards is welcome to apply for a job managing a git repo or something if such a thing exists? But I could harp on the same way about his missing MATLAB or firmware skills.

I wouldn't say I'm an expert but I've got about 10 years experience using git via CLI and whenever a noob does something weird and he's using an IDE I'm like... Sorry I have zero idea what this is trying to do and cannot help you

I've had similar experiences with git or other tools - not being able to help a junior dev because the GUI they're using is obfuscating whatever it is the underlying tool is trying to do. I think the irony is that we've got this insanely complex version control system that actually could have several valid use cases for what is likely a common path for users in a GUI.

I'm also not sure referring to people as "noobs" is going to help you empathize with their difficulty. ;)

Eh, that term seems to have fallen out of favor compared to when I was a growing up but I don't think it necessarily has a negative connotation.

I remember being in programming and software related IRCs at 10-11 years old having no earthly clue what in the fuck I was doing, asking adults questions and getting called a "noob".

Well, yeah, it was true. (I also made damn sure they had no idea I was a child.)

They could have said "inexperienced person" but that's not got quite the same ring and people are lazy, aye? Haha

My personal experience around noob is covered by the ones I found on ~~most~~ edit: the most high search-ranked online explanations: Mostly negatively conotated, deregatory version of newbie. Often associated with people not sufficiently able to learn or at least not learning on their own.


* https://en.wiktionary.org/wiki/noob

* https://www.etymonline.com/word/noob

Examples not containing the negative connotation:

* https://www.merriam-webster.com/dictionary/noob

* https://neologisms.rice.edu/index.php?a=term&d=1&t=2471

It might be something used quite differently by two similar groups, so it is good to be aware that other people may use it the other way.

I've been around long enough and in enough circles that I have seen 'noob' go from mildly chiding to full-on insult. It used to be that in some communities, being referred to as a noob was a sort of "hey check out the new guy" ribbing. A noob was just someone starting out, a neophyte. It was the impatient and rude who later decided that being a noob was a bad thing.

I often see people self-describe as noobs when asking technical questions, for example in programming Reddits. I couldn't say that I understand the reason for it, though.

Saying you're a novice when asking for help can be useful. People will use less jargon and point to more accessible resources, etc.

Noob is the first step to being a master. So, those "noob"s are indicating they're early in the process.

“Hey can you help me? I stood up a kratr pod and it’s lined to fundle but for some reason when I try to press the bin tree to the overlay layer the reznik instance on my laptop says ‘out of tokens’. Have you ever encountered this?” No, no I have not.

Having been troubleshooting computers since I was literally 8 years old (like I'm sure many of us here have) I feel reasonably comfortable I could at least be helpful solving this problem as well.

Every problem I have to troubleshoot is almost by definition one I've never encountered before.

100% Great attitude. I’ll meet you where you are and help out.

I can help. It doesn’t mean I’ve encountered it before.

Yup - Every darn time. Reminds me of "How it feels to learn JavaScript in 2016" https://news.ycombinator.com/item?id=12628921

Nothing has changed in 5 years, has it?

Let's hope not, then I can use it as a template.

The more things change, the more they stay the same

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 log --oneline --graph' the output was all pipes across my (maximized) terminal.

I've never seriously gotten into the 'plumbing' of git, so can't claim to have a 'true' vision of git via the CLI, but I've never yet been in a situation where it's been required.

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 the biggest corporations in the world, who build things that will kill people when they fail. I would love to blow the whistle, if I thought that would have any positive outcome whatsoever.

In my opinion this is way too much gate keeping.

Who defines which tools are "basic tools of the trade" and which are just bland infrastructure?

And who decides how much of each tool one should know to move beyond "daily incompetence"?

If I'm getting the job done and produce more net value than my peers for my salary, why should there be requirements on how well I know some specific tool?

I'm willing to bet a ton of value has been generated by folks who don't know the first thing about git beyond "commit, push, pull request". Who cares?

Now, of course, whatever my core job role is (perhaps it is firmware development, as in your example), I should know that role inside and out if my output is going into safety-critical places. But that's a different comment all together.

> In my opinion this is way too much gate keeping.

> Who defines which tools are "basic tools of the trade" and which are just bland infrastructure?

Well, if so many people routinely have so much difficulty with it as these comments witness, it can hardly be called "bland."

I'll admit as a 20yr c++ developer, I don't know what rebase is or when to use it. I've only been using git for a few years, cvs before that. I commit and push often, then do a merge request via a web portal gui(bitbucket or gitlab), then merge it squashing commits again using the gui.

I prefer merge/fast forward because I want all history preserved. People can rebase their changes in their branch, but rebasing is never done on the main or development branches. Most of the worst merge conflict I’ve had to deal with were caused by someone rebasing changes they didn’t make. I reject all pull requests that change history.

I think this is generally the place where you rebase. Right before things go into the develop branch.

We ask candidates the most ridiculous algorithm and data structure design questions when we should be asking them to describe the git data structures. Let’s fix interviews and kill two birds with one stone.

I do actually. If someone can describe to me what the (mechanical) difference is between a merge and rebase they’re likely to be better :P

Git is mostly one (clever) data structure.

Huh, how did it get so bad that "blow[ing] the whistle" about "things that will kill people when they fail" "would have [no] positive outcome whatsoever" ?!

I disagree, the point is to get code written that solves problems, and the tools are a means to that end and not an end in of themselves. Our tools should make that task easier and more accessible to more people.

Oh, boy, do you really want to say that? I have some questions about numerical algorithms that you probably rely on every day for you.

The point is that we care about the quality of the software at all times, not elegant graphs of its history.

I feel you. I was recently hired to help with svn to git migration and Java upgrades from 5-7 to 8 (due to my previous experience with such migrations). When I joined they already had a plan. They told me no one will be using command line. They are currently discussing which GUI to use and everyone will have this GUI installed by default, git command will be discouraged as non-standard approach, windows users will not have git-bash installed. I was asked for recommendation of GUI tooling for git and I had absolutely nothing to say, the only I ever used was Kraken and that was in 2014?. When I offered to train and assist everyone with git command training to make everyone more efficient in industry standardised tooling, they told me that's not in the plan. My job was done there without me having to do doing anything, I was free to leave that job!

Sublime merge would have been a good suggestion in this scenario. It's UI uses standard git terminology and concepts, so you'd have been sneakily trainig them in the command line whilst they used the UI!

It was in a very old fashion and regulated working environment where developers and testers aren't allowed to install whatever they want. Software installers can be whitelisted after a review is done. It included things like: licence OSS vs enterprise, support, community, or even more banal things like stars on github. Adding new software to a list could take literally months - like in case of git GUI client. Sublime was frequently requested but managers were responding "you already can install Eclipse and Intellij, you also have Notepad++, you don't need more editors. More editors installed is a security risk to this company!" (some hackers found a way to run VSCode portable edition which didn't offer updates ;)) This was end of discussion.

This is also why there was so so much fuss about git GUI client, there were looking for a golden hammer, a GUI that would do everything and anything.

The git GUI in Intellij and related products is really quite good. The diff view that shows three adjacent panes for conflict resolution (|theirs ->|merge|<-yours|) is so much better than the normal conflict resolution flow (not least because you still get the normal code highlighting in it), and separate checkboxes for each changed section of the diff makes it so easy to chunk large changes into logical commits. I wish they offered it as a standalone product.

What was their justification for being like that?

Sometimes I read these things and end up saying to myself "Wow, that company just literally hates being productive"

>What was their justification for being like that?

The more tools people are allowed to install and use, the less standardised software development. Meanwhile we didn't even have common source code formatting pattern and single Java class could be formatted with tabs, 2 spaces and 4 spaces.

Not necessarily. On my team at work we have people using Sublime Text, VS Code and vim, but all 3 (+ our CI) plug into ESLint and TypeScript for ensuring style coherence.

Why don't you encourage people to use their linters of choice? Why expect everyone to use ESLint?

If you want style coherence, the same linter with the same options makes sense. “Use your preferred linter” won't produce style coherence.

You should have recommended Emacs Magit just to see the looks on everyone's faces.

Funny enough, one argument against cli git was 'vim' as commit text editor ;) Maybe emacs would convince them!

Did changing GIT_EDITOR to something else not cross their minds? Or did they not even bother to check if it can be changed?

  EDITOR=joe git commit

I have 10 years of git cli and I use GitHub desktop or Sourcetree most of the time. I started using using a git IDE to help support the team members that weren’t experienced in git that chose to use one. I work in games and a lot of game developers mostly know Perforce.

I would never brush off a team member with “cannot help you”. I’m a git expert and I will figure out what’s wrong and fix it.

But are you an expert in the IDE? Are they having a problem with git or are they having a problem with the IDE?

Every IDE I know shows you a log of the raw commands its running. I use the IDE first, then if something goes wrong (which very very rarely happens, git isn't exactly complicated) I check the log and see what it's trying to do.

On top of that, the IDE will let you run git directly in an authenticated session if you really desire. If a simple/dumb GUI wrapper around git is enough to scare off an experienced developer, then I have my doubts about their competence.

It’s usually a mix of both ide and git issues. And yes I’ve become an expert in using Sourcetree and GitHub desktop. I actually like GitHub Desktop a lot and use it for most dev now.

Oh, I’ll figure out the problem alright. One git status on the command line aught to tell me what it is.

Good git GUIs (I use SmartGit and love it) do the following:

- use the same terminology as git

- show a log of every command

- default to sane behavior

- ask preferences instead of assuming (ex: rebase or merge?)

- show warnings when doing something destructive or unusual

I've found that I now spend zero time learning and thinking about git anymore, and it also protects our repos from git noobs at the same time.

Another SmartGit fan here. Adding to your list:

- Want a diff between two commits from two different branches? Click one commit and Ctrl+click the other. All the diffs show up immediately.

- Messed something up badly and you need to see the reflog? Click the Recyclable Commits checkbox, and everything in the reflog shows up just like any normal commit. And you can use the diff trick above on them.

- Wonder what's in your stashes that you forgot about? Click the Stashes checkbox and they all show up as normal commits. Because that's what a stash really is.

- Committed something to the wrong branch? Drag the branch markers to where you want them.

This is my main gripe about git, it’s literally a tool created to suit the guy managing the linux kernel development via mailing lists… What proportion of junior developers are even tangentially working on anything resembling that?

Even if it’s exceptionally wonky, I have absolutely no problem introducing git to new devs, as long as it’s alongside a graphical representation (sourcetree or some ide-extension), and as long as I am able to enforce limitations on what commands can be run on the git CLI (or more realistically, disallow push to master, and force every merge/rebase through a review)

I’ve personally found that it’s trivial to understand how IDEs integrate git and then adapt the workflow around that, but it’s a complete clusterfuck to let self-proclaimed git wizards loose on a repo without any structure..

> This is my main gripe about git, it’s literally a tool created to suit the guy managing the linux kernel development via mailing lists… What proportion of junior developers are even tangentially working on anything resembling that?

always did give me a chuckle how it took off the way it did for projects that don't come even remotely close to the scalability (like tree sizes) it provides.

the facts that it's free, fast, reliable, good for offline operation and can be used for huge and tiny projects alike are nice though. just never expected to see the day when web designers would become religious about using it.

I view it as a sort of hero-worship/cargo-cult thing... "Linus uses it (wrote it) so it must be the best!"

Yeah, hence see the criticisms of git from completely different sides from fossil devs on one hand and pijul dev(s?) on the other.

Git probably has its place, but only on very specific, large scale projects, with a crack core team and hundreds of drive-by contributors ?

> Git probably has its place, but only on very specific, large scale projects, with a crack core team and hundreds of drive-by contributors ?

So, hypothetically, if that were the case, what is the recommendation for Small/Medium web agencies?

No versioning at all, of course.

On a more serious note, I wonder if GP ever worked on projects outside of large enterprises and is just gatekeeping it. Git is useful on solo projects, for God's sake.

Useful? Yes. Way overkill? Also yes (imho).

HG is simpler to understand, has a more consistent CLI, and way better error messaging. Just a pity that it's been so sorely overshadowed by the Swiss Army Chainsaw of VCS.

Git can certainly do almost anything/everything anybody might want from a VCS, but, just like a chainsaw, it'll cut your leg off just as soon as it'll cut off the branch you're pruning if you're not fully expert in using it.

I understand that some GUIs sort of become "black boxes" while trying to abstract away the complexity, but I know at least one (Sublime Merge) that always shows you the low-level commands it's trying to run.

Same for me. I switched from SVN to git professionally in 2013 and used git via Sourcetree on personal smaller projects. I had to switch to the CLI git because so used SVN also on CLI only and could not transfer the documentation to the buttons of Sourcetree. Whenever I help out other coworkers with git do it via commandline. Doesn‘t matter if windows or Unix. What drives me nuts with programs like Sourcetree is the fact that they apply their own default behaviors to make it „easier“ to use git. Like initializing submodules by default. I had a project with a sparse checkout scheme that could not be cloned via Sourcetree because of this. Our submodules where an optional compiler for a 3rd party platform.

I completely agree. At work we still use SVN, so I'm used to TortoiseSVN which is OK imo. Now for GIT there's TortoiseGIT, but it was such a bad experience. The TortoiseSVN background made it even worse, because things seemed similar, but did totally different things. So weirdly, for SVN I still use Tortoise, but for GIT, I prefer the CLI client.

Specially when the ide doesn't use standard names and/or introduces new terms. Visual/ide tools to use git are welcome and I use them occasionally. But the cli should be the common denominator.

What about staging lines to the index? I tried ‘git add -i’, but it feels pretty clunky compared to selecting some lines with a mouse in git-gui.

git add -p

Oh thanks, that works fairly well. I still prefer git-gui for this, but this will work nicely when I'm ssh-ed into a machine with no GUI.

Magit is the king of staging and unstaging. You can even use it on remote systems via TRAMP.

That is true, but I think IntelliJ provides you with the list of commands it executed to get there.

Isn't that just being incredibly lazy. Surely a reasonably experience person like yourself should be able to read the error message and at least get a rough idea about what the problem is. Then from there explain how you would fix it on the CLI and try to map that onto the GUI. Most Git GUIs map fairly closely to the underlying git model.

Why not just say the truth "I could help you, but it's not my job, so I'm not going to"

> Most Git GUIs map fairly closely to the underlying git model.

Maybe, but most Git GUIs don't provide clear error messages. This is the case of VSCode, which my teamates keep using. When you use Git CLI you can just have the original error message and know what's wrong.

I was also burned by sourcetree some years ago where it lost part of my code while doing a merge I didn't even understand.

I am not a Git expert. But I can remember the 5 commands needed to do my job every day: `commit`, `push`, `pull`, `rebase`, `checkout`. (you can also add `add` and `status` to the list if you want)

They're straighforward, except for `checkout` which is adressed by `switch` for the main usage.

If you use it wrong, Git CLI will tell you in most of the cases, and even tell you how to do what you intented to do. Git GUIs will probably tell you something wrong happened and left you at that or try to be more intelligent than you are and do something wrong.

> Isn't that just being incredibly lazy.

-> this is what I'd answer to do those Git GUIs.

> Isn't that just being incredibly lazy.

-> this is what I'd say to people who won't write these 5 commands on a sticky note or something and keep it for a month before realizing it wasn't hard to remember once you _commit_ to it and that Git is not hard, minus exceptional problems but Git GUIs absolutely won't help you with these exceptional problems.

You can see the original error message in vscode by clicking "output" and navigating to Git in the dropdown.

If you are using a command line tool for 10 years and don't consider yourself an expert then either you are not using the tool very often or the tool is not well designed. In case of git I would say it is the latter. I mostly use git via tortoise interface and that works well 95% of the time. Other 5% is split between git mv, git branch -D, and trying various commands in order to make git do something simple that can't be done and then giving up. At this stage I see git as necessary evil rather than something that helps me with source version control.

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.

And second, what exactly mystifies you about what e.g. SourceTree menu commands do? They map clearly and intuitively to CLI commands.

If you have "no idea" what it's trying to do then you're not even trying to be helpful. You're just being condescending.

I get you disagree with the GPs post but “noob” isn’t offensive. What’s offensive is their lack of support for colleagues (which reads like a potential issue with their own ego: where they didnt want to be shown up in an unfamiliar UI). But their post reads exactly the same if you substituted “noob” for “newbie”, “junior”, “inexperience” etc.

What we need to do is get passed this ridiculous mindset some have that not knowing something is a bad thing. We all have to start off somewhere and “noob” is just a common term for describing that. Case in point: I’ll readily post “noob question guys, how do I…?” on Slack to give context that I’m asking a potentially basic question and basically don’t really know what I’m doing. For reference, I am the most senior on my team and yet I have zero issue highlighting stuff I don’t know when asking for help. And that’s exactly the way it should be.

There’s no shame in being new at something. What there should be is shame in wanting to mock newbies and shaming and those who don’t offer up their help to others. Being a noob should be celebrated as someone new joining the team rather than added to our dictionary of inappropriate terms.

I don’t think they meant noob as a pejorative.

Anyway, I’ve been the “resident git expert” before, and even just supporting competent CLI users is miserable once the team grows beyond 30 or so people. I can’t imagine trying to then reverse engineer and debug a half dozen crappy GUIs.

Optimizing everything around developers that can’t figure out the CLI sounds like a great way to attract bozos (both by admitting bozos and by chasing non-bozos out).

> Optimizing everything around developers that can’t figure out the CLI sounds like a great way to attract bozos

What about people who have totally figured out the CLI but still prefer to use a GUI?

I don't get why people act like it's either/or.

> which reads like a potential issue with their own ego: where they didn't want to be shown up in an unfamiliar UI > What there should be is shame ... those who don’t offer up their help to others

I read it more as, I don't want to be become L1 Tech Support for something I don't know either.

What happens when the GP runs into an issue themselves. Do their colleagues help him or return the same cold shoulder?

Computers are sufficiently advanced that there will always be blind spots in your team. Sometimes that means working together as a team to figure them out. Which is the kind of behaviour a good manager should encourage and the sort of attitude a good senior engineer should have already learned.

The issue isn't the technical complexity, it's the office politics.

If they fix it, do they then become responsible for fixing it in future? Is this now a "responsibility" the "company" (coworkers) expects of them, with no compensation? In addition to their existing responsibilities?

I introduced git to the company I'm at (previously on SVN running on an old beige box in the corner). It made collaboration easier. I accepted the fact I'll get pinged whenever someone makes git do a weird thing, but I'm lucky that for the most part coworkers learn from these incidents rather than coming back each time with the same issues.

Again, it shouldn’t be a matter of office politics. If you have a healthy team then everyone will chip in their individual strengths. Yours might be git but someone else might be stronger with Bash, package management, or whatever. Eventually you end up with everyone helping each other. So while you might get interrupted occasionally for git queries, you’d save hours on another issue that someone else helped you with.

There should also be schemes in place to help people level up their own skills. Whether it’s organised training days or an acknowledgment that x number of hours a sprint is spent on personal development (A Cloud Guru or whatever).

If a company doesn’t set up those two pillars then they risk creating toxic teams and that’s ultimately more harmful for productivity than any lost time in a given day helping a peer with version control.

Source: been a hiring manager at several companies. Seen what works and what doesn’t. Ultimately a closer team almost always out performs one where individuals are only looking out for themselves.

> 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 expense at the most inconvenient times."

Being offended by noob just makes communication more difficult, and does not really change anything. We've had all kinds of much more offensive names for the same thing (many other names imply race, social status and so on). noob seems to be about as offensive as rookie, but one syllable less.

Newbie is a nicer word.

Noob is just a contraction of Newbie. Newbie -> Newb -> Noob. It's still used interchangeably with Newb.


"Noob" has a negative connotation.


> Contrary to the belief of many, a noob/n00b and a newbie/newb are not the same thing. Newbs are those who are new to some task* and are very beginner at it, possibly a little overconfident about it, but they are willing to learn and fix their errors to move out of that stage. n00bs, on the other hand, know little and have no will to learn any more. They expect people to do the work for them and then expect to get praised about it

The specifics of the definition probably vary depending on who you ask but that's roughly it.

Indeed, and it should be clear that "noob" is intentionally/cleverly spelled like "boob" in the sense of "idiot". That's the whole point of the word -- that's the joke.

Now it's fine to joke around and call yourself a noob, that's just self-deprecating.

But if you're talking about other people and don't want to inadvertently offend, stick to "newbie" in speech or "newbie/newb" in writing, which have a connotation entirely of "beginner" as opposed to "idiot".

(Of course, if you're among friends where you enjoy making fun of each other, say whatever you want!)

I've been using the term noob for decades. Reading your comment is the first time I've ever seen anyone compare it with boob. There is a big world out there, with lots of different people using words to mean things.

Well it's certainly widely established that "noob" is more derogatory [1] [2]. Take that for what you will when you choose to use it.

[1] https://www.etymonline.com/word/noob

[2] https://en.wikipedia.org/wiki/Newbie#Connotations_of_variant...

Beginner or junior developer works. Noob has a history of being used in a derogatory sense, so that's how many people read it.

I agree with your last paragraph but "noob" is offensive? That's just silly... it's like you said, we've all been there once and it's a useful term for quickly describing where one's at. There's no inherent malice unless intentionally added by the speaker/poster.

Just as a data point, I unselfconsciously describe myself as a noob (or more likely n00b) when I'm inexperienced with something, and still prone to making embarrassing mistakes because I don't know what I'm doing.

I don’t completely agree.

> My job isn’t to use git, it’s to write specialist software.

I’m a big fan of automation, but there are certain fundamental tools I think one needs to understand to do the job. Both because you should have some idea what the automation is there to accomplish and also to get yourself out of a pickle when something goes wrong (or to even recognize when that happens!).

So, as I think most people would agree: you certainly don’t need to understand the obscure corners of your programming language, but you should have a solid understanding of the fundamentals and a decent overview of the rest.

In the case of source control, and git in particular, IMHO you should have a decent fundamental understanding (which isn’t even particularly complex at a conceptual level) so even if you don’t remember the command for ‘X’ , you’ll know to look for it when you do need it.

Given how you started your comment, perhaps you don’t even agree with implication of the sentence I quoted.

(edit: added IMHO)

I'd go even farther than not completely agreeing with that and just say that I completely disagree. Our job as programmers is not just to write a bunch of code in a vacuum, it is to create that code and communicate it to the machines and people who will be consuming and manipulating it.

Things like version control should be first class tools that we all learn in detail. They are literally the most fundamentally important tools we use every day if we work in a team. You aren't doing your job if you don't care about how your code interacts with your team and your deployment. Like an architect who doesn't know how to use a drafting table.

It's incredibly frustrating that people let their egos stoke them into this idea that tooling is beneath them. It's almost certainly the cause of an incredible amount of bad software, even though much of its code is, I'm sure, quite clever in a vacuum.

And I'd rather work with a hundred programmers who know how to use their tools than one programmer who looks down on them for it.

I don't understand how "using a GUI to drive this tool" instead of "using a CLI to drive this tool" means someone doesn't understand version control, doesn't care about how their code interacts with their team, or doesn't know how the tool works.

I don't understand how I'm supposed to reply to this given that it claims I said something I didn't even come close to saying and has nothing to do with what either me or the GP post were replying to.

If you want to try again, the central thesis of my post was:

"Using git (or some kind of version control) is, in fact, your job."

With a digression that amounts to:

"The disdain OP's post shows towards people who take the time to understand the tools fundamental to performing their job is extremely unappealing to me in a coworker" (ie. the "they should get a job managing a git repo or something" part)

How should one go about achieving a 'decent fundamental understanding' (specific pointers, if you have them). And, how much time must one devote to being a 'good enough git guru'? (and, it surprises me that gitless is not more popular: https://gitless.com/ )

> 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 <ide> 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 the cabinets built and the customer is happy, it doesn't matter whether I use a japanese handsaw or a CNC controlled laser. Imagine having 100 different pieces bouncing around around in your and having to then remember the assembly order."

Now, you might argue that this supports your point, by claiming that it actually doesn't matter whether the carpenter uses a japanese handsaw, table saw or CNC laser cutter. But I'd argue the opposite: it does matter whether the carpenter knows the tools they use as well as possible, because this will affect both the quality & speed of their work, but also the range of possibilities they can even consider. It doesn't matter much which tool they use, as long as they know it intimately and in depth.

I would argue that the same is true of the tools we use as software developers. Pretending that all of the skill lies only in the domain of creating actual lines of code is misleading. If you're using a revision control system, you owe it to yourself, your customers and your colleagues (if any) to be a master of that in the same way that you're a master of the specialist software you're creating.

> But I'd argue the opposite: it does matter whether the carpenter knows the tools they use as well as possible, because this will affect both the quality & speed of their work

You chose a strange analogy, because CNC woodworking is far and away the superior choice over hand tools for producing cabinets. CNC cut and drilled wood is going to be orders of magnitude cheaper, more accurate, and allow the cabinet professional to focus on what really matters (installing them properly) rather than wasting huge amounts of time trying to do everything the manual way.

Ironically, this might be a great analogy to support the OP's point: Someone who gets so caught up in the tools and methods and doing everything the manual way for the sake of flexing their knowledge is at risk of wasting a lot of time and energy.

Personally, I have a lot of fun doing things the hard, manual way when I'm working on a hobby project. But when it's time to get work done, I choose the efficient abstractions and tools that let me focus on the core work without wasting time.

If you have a CNC system, then I'd say you should absolutely be using that in preference to other things. But you should also come to as deep an understanding of the CNC system as possible, so as to be able to grasp what you can do with it, and how you could use it to carry out specific tasks that might arise in the course of your work.

What you should not do, IMO, is to say "Oh, I have a CNC system, but I never interact with it directly, I let CNC-Foo on my computer control it whenever I need to do anything".

> What you should not do, IMO, is to say "Oh, I have a CNC system, but I never interact with it directly, I let CNC-Foo on my computer control it whenever I need to do anything".

I have experience with CNC machines, and I would still not recommend that anyone try to control their CNC machine by typing in G-Code directly. Understanding G-code can be helpful, but you really need to learn to use the higher-level tools properly to get anything done.

HN is really strange on the topic of knowing the underlying details of complex systems:

- When the topic of CS interviews comes up, the comment section is irate that companies are testing for low-level knowledge that isn't used in day to day programming tasks. Asking someone to reverse a linked list is blasphemy because we have libraries for that.

- When the topic of Git comes up, the comment section is insistent that the only possible way to use tools is to have intimate working knowledge of the underlying low-level concepts. Insisting that people know the ins and outs of every git command instead of using a GUI is the only acceptable option.

I suspect there's a lot of overlap between the two positions, which boils down to: "I do things a certain way and I'm convinced my way is the correct and only way."

1) I don't think it ever makes much sense to have a concept such as "HN is really strange on ...". This place is a collection of thousands of individuals, and you're going to see a wide range of opinions, many of them contradictory. Since not everyone comments on every article, you'll see patterns that are not reflections of a single position held by any particular person. If you see contradictions in things that I've written, I'd love to have them pointed out, but saying that "one set of people on HN say X and another set of people on HN say !X or X'" just doesn't really convey anything that seems actionable or even that interesting. "People have different opinions! News at 11!!"

2) After I posted the comment you're replying to, I was absolutely certain that the question of which level of control was appropriate would come up (since that's really what we're discussing in the context of git). It doesn't seem obvious to try to carry the analogy too far, but for both systems there are obviously different levels that one can think about. I haven't used a CNC system, but I would imagine that there are very high level control systems that maybe start from some sort of design data and take it from there, some mid-level control systems that let you specify what you need and then program the machine to create it, and low-level control that would be rarely used unless the higher level tools just couldn't do what was needed.

If indeed this is an accurate description, then it seems to match the case with git quite well, and I'd still argue that even if you often/sometimes use the very high level control tool, you should understand and be aware of the possibilities of the lower level ones too.

> 1) I don't think it ever makes much sense to have a concept such as "HN is really strange on ...".

I enjoy HN, but I've also been here long enough to accept that HN is an echo chamber. Yes, we have downvotes and a variety of opinions, but the reality is that if you come into certain threads expressing certain unpopular opinions you're going to get hit with a wave of downvotes. Eventually you learn to just stop posting those opinions, which results in an echo chamber effect.

No social media site is free of echo chamber effects. HN is not an exception.

> I haven't used a CNC system, but...

Friendly suggestion: If you're not familiar with how something works, maybe it's not the best subject for an analogy?

"Haven't used" isn't the same as "have never been in a shop with a CNC system installed, never worked around people using them, and have no close friends who use them regularly".

As for the echo chamber, you won't be suprised that I disagree with you on this point.

It would be perfectly reasonable for someone to just say "no, I'm not going to imagine my job designing software as analogous to cabinetry," because argument from analogy shifts some of the burden of proof to the analogy itself, and the analogy must be defensible. In this case, you're drawing an equivalence between OP's 100 complex things and 100 cabinet components that must be assembled, yet also drawing an equivalence between the 101st thing and a central tool of the cabinet maker's trade. This is an internal inconsistency. You must either acknowledge the 100 things as 100 tools of cabinetry, each more important than the 101st, or you must regard the 101st thing as yet another fixture to be added to the cabinet. A domain expert is telling you that version control is a peripheral concern in their trade, the 101st tool, and you're responding with an idealism of mastery that stems from notions of integrity and identity and establishes no reasonable boundaries. You're welcome to this ethic and idealism, it's not a bad thing to have, but you're second guessing someone else's mastery based on arbitrary reference to your own mastery. I might as well be chiding you for looking up man pages without understanding the command-line capabilities of `troff`.

> A domain expert is telling you that version control is a peripheral concern in their trade

1) I have no way of knowing if they're a domain expert.

2) With 35 years of software development under my belt, and a half dozen version control systems too, I'd consider myself likely to be as much of a domain expert as the OP, and I'm saying the opposite.

3) I am not as master woodworker. I have built cabinets and many other things. Philosophically I consider the disjunction between our culture's attitude towards physical tools (where there's an assumption that one will have to take time to learn how to use the tool before actually being able to make anything good with them) and digital tools (where there's an assumption that apprenticeship should be kept to a minimum, preferably zero) extremely interesting.

4) When I'm working on a task (I also build very specialized, highly complex software) the distinction between the cognitive load caused by the task and the cognitive task caused by the tools I have available to work with is not very big. It doesn't make much different whether the "101st" thing concerns a tool or a component, it's just another part of the big picture that I have to struggle to keep in my head as I move forward.

This is an excellent reply, more interesting than my comment, and I certainly cannot gainsay you. However, '100' might as well be 'n'. Your reply suggests that there is a struggle to maintain contextual awareness of 'n'. In this model, for everyone, there will be an n+1, a necessary factor where the diminishing returns of mastery do not justify the cognitive load. I do not think the heart of your dispute truly lies so much his model of peripheral necessities as with his ranking of git as an n+1 tool.

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 personal preference is.

I flagged this because this is extremely dangerous advice.

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.

Now I'm curious: why? Not that I don't believe you, but I'm wondering what is the reason? It's not intuitively clear why gloves would make it more dangerous, even knowing that it is.

If a glove comes into contact with a spinning blade, there is a good chance it will pull the rest of the glove, and the hand within it, right into the path of the blade.

Aha! That is one of those things that never crossed my mind, but makes perfect sense once explained.

I had a hand saw in mind...

Speaking as a person who lost half a thumb to a table saw ...

the difference in your analogy emerges when someone wants/needs you to carve out something more intricate, and you say "it's not my job to be able to do this without gloves".

To the op's point, using git is not the act of coding or in this example making cabinets. I think it would be more akin to a work flow used by a cabinet maker and I think people would be less likely to look down on one that has an idiosyncratic work flow. It may not be the most optimal work flow, but they can get the job done well following their methods.

I don't subscribe to that thinking and I try to optimize and improve wherever I can, but developers are an idiosyncratic bunch. You can lead them to water or show them how to fish but lots of good developers just like to do things their own way.

It's about tools. Git (and revision/version control more generally) is a tool available for you to use when developing software. The questions for me are: do you use the tool? do you understand the tool?

I think it's fine if someone says "I don't use that tool". I personally think that they are making their life harder and their software probably worse, but that seems like a valid choice. What I have a difficult time with is someone who says "I use that tool, but I limit my understanding of it to be as little as I can, because understanding my tools is not part of my job". That's what I felt the OP was doing.

Surely some tools have to be more important than others tho and not knowing some tools impacts some jobs less. Is git a saw for woodworking? Or is it a tool chest that has a drawer for a saw? If you need to use a thousand different tools, the tool chest becomes more important (the analogy doesn't map well there but it seems similar to working on a bunch of repos that have a bunch of branches or one repo with one branch). If you only need a handful, it seems like it would impact your job less.

There are more things that reasoning applies to than you can learn, so it’s not really helpful in deciding between all the things. Everything depends on your goals and there’s no one size fits all answer.

In your anecdote, git wouldn’t even qualify as a tool, it would be the weird storage space with an over-inflated sense of importance.

Version control isn't a tool I use. It's the filesystem I store my files in.

Would you use an accountant who doesn’t think it’s important to know how to file documents, or that their file cabinets are even a tool of the trade?

I know how to file documents in filing cabinets. I don't know how the bearing mechanism for sliding out the drawers work, or how to replace the user-serviceable locks – but I know that there's a mechanism, and that the locks are user-serviceable, and I could look up the relevant information if I ever needed to do anything with that.

You don't need much knowledge of your version-control system in your head to be an effective programmer.

This is only true until the first merge conflict or when you want to know when a bug was introduced to even find its location.

I resolve conflicts in GUI every week.

I find the location of a bug by running tests and looking at the code.

git bisect will optimize the number of tests you have to run, and will reduce the amount of code you have to look at it to the minimum (in general).

Assuming a binary search over version history is a valid way of finding the bug. If you have a better idea of the probability distribution (e.g. it might've started being buggy any time in the past year, but I'm fairly sure it happened about nine months ago when the formatting of the report broke a bit) you can do a better job manually than `git bisect` – and if the bug is actually multiple bugs, or other things changed that affected the bug's presence or absence (making it appear or disappear in non-trivial patterns between versions), `git bisect` will mislead you.

`git bisect` is pretty cool, but “knowing your tools” isn't the same thing as “memorising the man pages”.

if you are confident that it happened about nine months ago, then just start the bisect bounded by age-appropriate commits. just a case of knowing your tools ;)

yes, if the bug is a complex interaction of several different code changes, and comes and goes, then a binary search will not find it. however, it may be the fastest way to realize that it is this sort of bug. recognizing patterns in what happens when you use git bisect is another aspect of knowing your tools, and in this case, will help you move more rapidly toward a more appropriate approach.

I interpreted what GP said as " the version control system is the place I store my files, so it's not just a tool, but it's an essential and necessary environment, the space where I organize my stuff"

That's more what I was going for. It's also part of the background, as opposed to something I deliberately interact with, so I don't use it like a tool in my day-to-day.

All things I know are possible. I understand Git's architecture, just like I know what an inode is. I could re-implement my own (bad) version control system, if I wanted to, just like I could make my own (bad) filesystem.

But that doesn't mean I need to have memorised the CLI invocations. There's a button in Git GUI for all the things I need to do (including the things you've listed), and in the rare case where I need to do something else (e.g. submodules), I can look it up, just as I do in the rare case where I need to make a symbolic link.

Thats a quite different statement from vcs not being a tool you use. At least how I read it.

All visual git tools I've used suck and wound up eventually corrupting the repo. Also I've noticed that all of my colleagues who learned git using these visual tools didn't actually learn git, and have no idea how to anything other than add/commit/push.

I say "just rebase your branch" and I can see the panic grow in their eyes.

> I say "just rebase your branch" and I can see the panic grow in their eyes.

The irony of that is that resolving conflicts in a complicated multi-commit rebase is much more easily/efficiently done in a good GUI than on the command line. Not all GUIs support it though (I think SourceTree gives up if there's a conflict), in fact it's a bit of an acid test for a Git GUI. The Jetbrains IDEs (PyCharm, CLion, IDEA, etc.) work very well. (So does TortoiseHg but obviously not for Git!)

Magit[1] is also excellent. And like all good git tools it exposes a log of what it did. Unfortunately it doesn't work so great with megarepos, but I understand that's being worked on. One area where this tooling is vastly superior to the command line is adding hunks instead of files to a commit, making it much easier to have a sensible history while allowing programming in a more natural style.

[1] https://magit.vc/

+100 for Magit. My favorite feature is rebasing directly on logs.

My experience also supports this. I think resolving complicated merge conflicts is the best argument for using an IDE with Git. My experience of having to maintain a fork of a code base where there was frequently a lot of conflicts showed that I would reach for IntelliJ to resolve complicated conflicts even if it wasn’t Java files. The 3 window visualization they use is just great for seeing conflicts in large files that span hundreds of lines of code.

I use the terminal commands for everything else though.

> The irony of that is that resolving conflicts in a complicated multi-commit rebase is much more easily/efficiently done in a good GUI than on the command line.

This is an argument for a good GUI diff/merge tool, which is not necessarily the same thing as an argument for a GUI Git client; I think the two uses are being conflated a lot throughout this comment thread. I have Kaleidoscope set as my default mergetool and difftool, but I'm still working with the git CLI nearly all the time. (I use Gitup on the occasions I want to stage changes to individual sets of lines in the same file as multiple commits, and exceedingly rarely if I'm trying to do something frightening with a local as-yet-unshared feature branch. There are times being able to undo with Cmd-Z is really helpful.)

You're right that there are two different parts to a these, but I think they both benefit from graphical tools.

I'm talking about a VCS tool telling me that the rebase had got to commit n of m and a conflict has been encountered, and which files have conflicts resolved (either automatically or I've manually resolved then so far in this tool), and which other files have conflicts outstanding. Then I can invoke the three way merge tool from there (which is indeed hugely better than a command line tool). Something like this (except this is for Hg):


I use Meld in case there are conflicts of these types. The CLI can be configured for that, and mine is set up that way.

But truly, I never just use plain pull, but pull --rebase, and I have not experienced such a conflict in years.

The commit history also stays a bit more linear. (Other developers use normal pull).

I learned git with the CLI. Occasionally I will use it.

But I see no reason to not use Jetbrains beautiful beautiful git integration for almost everything. It really is just ... perfect.

But if people want to feel superior by typing commands in a terminal, go ahead.

SourceTree doesn’t give up. It tells you that you have conflicts to resolve. Once you do, “continue rebase” does what it says, either until the rebase completes or until it hits another conflict.

Does it show a GUI, analogous to [1], or tell me to sort it out myself on the command line? I'd it's the latter then that's very much giving up. On the other hand, it's possible I'm mixing it up with some other GUI I tried.

If a rebase encounters conflicts, it tells you as much, puts every piece of the commit that it could auto-merge into the index, and adds conflict markers to what it couldn’t in the working tree. Then it’s up to you to merge them in an IDE or Optionally (I think) choose yours / theirs for each hunk. Once everything is resolved and moved to the index, “continue rebase” goes on to the next commit.

I think it’s had a rebase GUI since I first started using it in 2013. It may not have had one back then for interactive rebase, or else it didn’t work for me, but it does now.

[1] was meant to be this, which is the TortoiseHg merge conflicts window:


It’s not as nice as that one. I described it in my other comment. The workflow is okay, but that visual context of to/from branches in your screenshot is something I wish SourceTree had.

I would say that depends on your background.

This is just me but I’m quite happy viewing the graph via CLI and doing interactive rebases to fix issues.

I have no problems with other people preferring a GUI but all I’ve tried have been confusing for me.

Sublime Merge’s three-way merge is so good. It’s totally spoiled me.

Is sublime doing the merge instead of git? Or are you referring to use sublime as the merge tool to resolve conflicts?

Sublime Merge is a GUI git/mergetool, from the makers of Sublime Text.

Just for resolving conflicts.

I actually agree, using a nice GUI to handle your merges is a godsend. If you know how to use it properly, and still know how to do more advanced operations as well.

Vim has some plugins that make it a lot easier/quicker.

A combination of git diff, git checkout --ours/theirs . && git add and git mergetool works well in my experience

For these people, I think a manual backup is what they actually want. “If I fuck up so bad I have to roll back.” I don’t think it’s wrong necessarily either, and GitHub actually encourages this behavior with the easy Web file uploads. Many repositories are now 99% automatically created commits by drag and drop.

I think these people would be better served by a backup system where you can pin snapshots. They don’t really want to use VCSs like they’re meant to be.

How are version control systems meant to be used, if not as a history of the work? If not as a remote backup of work in progress?

I get the whole “we should have a neat history of feature commits” argument, but that’s really only one facet of a good source control system.

The fact that these goals appear to conflict shows me there’s some sort of lack in git. For all its (many, many) problems, uber-complex source control system ClearCase at least allowed you to specify a view, so you could see both types of information depending on your use-case.

They’re not really in conflict at all. The workflow I’ve been using for ~11 years is:

- Make a branch for my work.

- Commit early, often and with often meaningless commit messages like “WIP” or “try x” or “nope x doesn’t work, do y instead” - in other words, what the work was.

- Push this branch to a remote (either personal or shared depending on policy) largely to synchronise between machines, but also as a backup.

- When ready to integrate, interactively rebase into a set of cohesive units which are independently buildable and have detailed commit messages which explain why the work was done, not what the works was.

- Push _this_ as a pull request, Gerrit change set, or email patch, depending on policy.

This approach gives you the best of both worlds: fast, easy backup and easy unwind when doing work, and a clean history for the benefit of future developers on the project.

You still lose your real commit history though, and I’ve found it useful to have that in the past. A dead end or experimental avenue that turned out not to have use at the time turns out to be a real timesaver later.

I’m fact I’ve found that far more useful than a well curated history.

Having both would be a good thing. Having both in a not-ridiculously overcomplex system even better… I wonder if there even is a sweet spot.

I agree that having both would be preferable - and to some extent GitHub gives you that (via the "squash and merge" button). Unfortunately it doesn't appear that workflow is usable in a lot of cases since the commit message cannot be reviewed independently in this model, unlike in Gerrit.

You can always keep your working branches on a personal remote, or interesting sets of changes in gists, however.

> You can always keep your working branches on a personal remote

This kinda defeats the point again, to my view. I’m not familiar enough with gists to know if they would solve this.

Too bad for them, because they're (supposedly) professional software developers hired to work on this project and the project uses git.

The only visual git tool I really like is gitextensions for windows.

Fork has its advantages too (and a slicker UI if that matters for you)

I will agree that visually seeing the tree is such a useful tool to have access to. I know that's not the true desire of your use case, but in case it's useful, I will add what is obviously the best git alias, 'git lg': https://coderwall.com/p/euwpig/a-better-git-log

git lg --all is probably my most used command in terminals and I think it gives me a better view of how projects are flowing on the whole.

If I need to visualize the network of commits I use this alias in .gitconfig:

network = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all

I'd rather use a "visual tool" to visualize

No apparently that means you don’t know what you’re doing, and you’ll corrupt the repo, and you’re not a real software developer so we’ll come to your desk and rip up your I’m A Very Serious Professional card.

It's funny, because most devs that are pro CLI for these kind of things, are actually unable to operate vi, or install any server / container without installing a complete desktop environment.

Let's all go back to the ed line editor

And that's totally valid. gitk is my main experience with visual git tools and using it gives a ton of information that is not only visually nice to look at, but also pretty easy to navigate. But gitk isn't always the most available and sometimes I just need a quick look at the history. They're all just tools in the toolbox, but even knowing the tool exists is a first step.

and the ultimate option for git lg is --reflog. Seeing all branches, even the old ones that do not exist anymore is a eye opening event in discovering the true nature of git: it never changes a commit, ever.

While reflog is amazing, the "ever" in your statement is not true, `git gc` will prune your reflog: https://git-scm.com/docs/git-gc

Most of the time this doesn't matter in practice but you should be aware that unreachable refs don't stay around forever.

I exclusively use git via the cli because guis are too confusing for me to keep track of what is going on, I also like to use tig to browse the commit history like above.

Seriously, seeing the commit tree laid out with colored lines is essential to me. A glance at the interface lets me know exactly what state the repository is in. Just like you say, it's less mistakes. Which is precisely one of the benefits of good UX.

Going from SourceTree back to the command line would be a huge step backwards for me. I still use the command line sometimes because there's advanced stuff SourceTree can't do. But for most of my basic everyday operations, the command line is just inviting me to make little accidental mistakes every so often because the state of the repository and branches isn't obvious at a glance.

I only see upside to using an IDE, zero downside. (I've never had SourceTree "corrupt" my repository, and all its commands do exactly what I expect -- it's just running the git commands I'd be typing out anyways.)

Yeah, viewing a changeset and staging only some files or just parts of files is really important to my workflow. Sometimes I leave myself comments or skip tests locally and I have no intention of committing those changes. Using a tool like sourcetree to review, add, and commit only the lines I want is very helpful and saves me time.

I do use the command line for everything else, though. Well except interactive rebasing, I suppose. I pop back in to vscode for that. But even that gets started in the terminal.

I’m in the same camp, often staging is easier to handle with a GUI, particularly if you want a partial staging.

But then again, there is always git add -p

This is also part of my workflow, that I use git commit -p instead. Seems weird to only use a tool for that part when git's included workflow is perfectly capable

My most favorite shell alias is `gap`:

    alias gap="git add -p"
Probably SourceTree makes this workflow better (git add -p is a forward-only workflow, so you can't glance up and down a file, for example), but it's so ingrained in my fingers that I'd have a hard time switching things up.

Just in case you didn't know, there is git add -p (or --patch) which does precisely what you want: It splits your changes into small parts ("hunks") and allows you to specify whether to stage every hunk. I don't know your exact workflow in Sourcetree, but most likely git add -p is the CLI equivalent of the Sourcetree interaction you describe.

Bonus commands: -p/--patch also works for git stash (allowing you to stash only certain changes) and for git checkout (allowing you to discard only certain changes). Since I'm an Old School Git user I actually don't really know the restore/switch commands, but apparently git restore supports -p/--patch as well.

Another neat git add flag is -u/--update: The manpage is a little confusing on this flag, but essentially it makes git add ignore untracked files (it will only stage files that are already part of the repository). If you're like me, you have tons of files laying around in the project folder (e.g. benchmark results or local test input files) that you don't want to commit and yet don't want to add to the .gitignore file (since the files are really just temporary files, other users have no use for the gitignore entries). By using git add -u, you prevent adding them by mistake in a command like git add src/ and realizing a few weeks later that you accidentally added 10 MB of cat pictures to a bugfix commit. If you can identify with this story then git add -u is made for you.

Another bonus fact: If the temporary testing files mentioned in the last paragraph ever reach the status of permanent testing files, and they're still only useful to you personally (so adding them to gitignore doesn't make sense), Git has a little-known feature: You can add local ignore patterns (same syntax as gitignore) to .git/info/exclude (go ahead and check, this file most likely already exists in your Git repository). These patterns are not be part of the repository itself (you don't commit them), rather they act as local configuration. The idea is that you put exclude patterns that are valid for every user of the project (e.g. target/ for a Rust project) in .gitignore, and local exclude patterns for your IDE/editor configuration (.vscode/, .idea/ and friends) and similar files in .git/info/exclude.

In conclusion, I only every run a) git add -u $file (when I want to add all changes made to an existing file), b) git add -p $file (when I want to add only certain changes made to an existing file), or c) git add $new_file (when I consciously want to add a previously untracked file).

These three commands are all you need if you're in the camp of Git users that at least try to make every commit a good package (single, reasonably-scoped and atomic change). If you're in the git commit -a/"squash all intermediate commits into one single monstrous commit" camp then.. have fun with your cat pictures, I guess.

I hope that was at least a little bit helpful to someone.

May I ask why you drop into VS Code for interactive rebasing? Is it about resolving the merge conflicts, or editing the rebase command list? I'm just going to drop two more nice Git features here, but I'll stop myself now before I write too much: git commit --fixup= together with git rebase --autosquash, and git rerere (not a typo).

I completely agree. It always baffles me how something so simple (yes, simple!) as version control can end up as the abomination that is git. After controlling for popularity, you don’t see nearly as much posts explaining subversion in detail, and subversion being centralized is neither the only nor the biggest reason for that.

No, version control is not simple, never was. git was the first vcs that didn't suck because it was the first tool that understood the nature of the problem. All others were ass backward and instead of solving the problem stood in the way and actively made things worse.

Wow, I’d never call version control simple. Actually it’s fiendishly hard. Git makes some simplifications (!) to make the problem more tractable.

What VCS system is simpler? I've used mercurial, svn and git, and git seems the far easier of that sample space.

Git's basic problem is that it has a really a good model for the data, but a really terrible CLI.

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 doomed to failure.

You assume that the creator of one of the.. if not the largest open source projects on the planet might not understand the issue at hand better than literally anyone?

That seems arrogant. I imagine more thought & care went into git than you can fathom.

If "the issue at hand" is running a globe-spanning open-source project with hundreds of contributors, a bunch of targets, and a code base that goes back 30 years, sure, I'm happy to listen to Torvalds.

if "the issue at hand" is the more typical modern work environment for devleopers, then no, I don't think he has much special insight. Indeed, the fact that he's wrangling something so large and important means he's unlikely to have the time and attention to devote a lot of thought to how best to serve a pretty different group of people.

An obvious consequence of this is git's terrible interface. Its premise is "if you totally understand what Git is up to under the hood, the interface is great!" Fine for a small in-group of kernel developers whose lives are distributed patch sets, but terrible for the average developer. It has taken 15 years to get some reasonably named commands for common things like "restore a file". That's a great sign that we shouldn't listen to Torvalds on topics outside the realm of his admittedly impressive expertise.

This isn't about "understanding the issue at hand," this is about UX development.

Linux is, very intentionally, a piece of software which does not have "easy to understand for non-experts" in its design goals. You generally interface through Linux with system call wrappers provided by a libc (or another specialist library for other interfaces like libfuse or libnetfilter or whatever), not directly. Linus is, quite obviously, good at many things; it's silly to assume that means he's an expert at everything.

Linus developed Git as a low-level tool. Linus put a lot of thought and care into getting the implementation details right, but intentionally did not build an easy-to-use interface. The Git command line that people use today ultimately derives from Cogito, a toolkit written by someone not Linus that sat on top of Git. Eventually Git (which Linus had long since handed off to someone else) adopted most of the conventions of Cogito and created a "porcelain"/"plumbing" split. If you think it was arrogant to develop Cogito, I suspect you disagree with Linus.

Finally, Linus develops Linux with a very particular model, with e-mail-based patch reviews, merges from subsystem maintainers, etc. Most projects (even most open-source projects, but certainly almost all proprietary projects) do not work this way. The Linux kernel does not use a GitHub-style workflow for development, which is by far the most common way people outside the kernel community use Git. It may well be the case that a lot of thought was put into making Git work really well for Linus's use case but it does not match how other people do development.

The difference between the kernel development model, and some putative "typical other" development model merely changes which git commands/tools get used to handle getting stuff into a particular branch on the canonical repo.

It has no impact on the underlying concepts that make git scale well, cover 100% and 100% remote cases equally well, and provide deep under-the-hood concepts that can be deployed in exceptional circumstances.

Correct, it has no impact on the internals of Git, which was my point. Git's internals are used by both the kernel development workflow and the GitHub-style workflow, and Linus designed it well.

The conversation is about the user experience of using Git - its CLI design, etc. It is entirely about "merely" what commands are being used. TFA is about new Git commands, not about any changed internals. Or, in the case of Sourcetree, it's about not using any of "Linus's" interface to Git (which, again, wasn't written by Linus) but interacting with the same Git internals.

I think the conversation is about whether or not the Sourcetree interface to git can be useful when carrying out tasks that involve, for example, filtering the reflog.

If you have never done this before, and have only ever used git via the ST interface, switching to the CLI to get this done is going to be quite a shock. Maybe that's OK because realistically such tasks should be rare. But sometimes they are a critical task in development, and finding that the entire dev team is completely intimidated by it can be an issue.

Isn't that the "appeal to authority" fallacy? Mercurial demonstrates that you can have a VCS with less painful and frequent gotchas and certainly the grottiness of the git submodule mechanics, for example, doesn't show as much thought and care as one would hope.

How does Mercurial show it? I always found it very confusing to use all the times I tried it so I would need some context to understand your comment.

No, we use it because it's superior to the competition.

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.

As someone about to migrate from Mercurial to Git i absolutely agree that Git is the superior tool.

Pull Requests were never going to happen with Mercurial and it's also not possible to delete a branch without some black magic server-side.

And with Git hopefully it will be possible to move to Trunk-based development, although that requires a lot more than just switching to Git.

There are at least two different commercial hosting sites that implement a pull request model. If you want ephemeral branches like in git, hg branches are indeed not the right choice. But that doesn't mean that they don't have their place. Try topic or bookmarks if you want gitish behavior.I have absolutely no clue what you mean with trunk-based development...

We might have been able to do pull requests in Mercurial, but were using a special tool to manage multiple Mercurial repos.

Trunk-based development is where you use a single branch for development, instead of multiple branches that you have to merge between.

More info at:


Funny, I rarely use branches (or topics) in Mercurial unless it is a complicated long-term project. Modern "everything on a branch" was invented by git users because the UI forces naming things. Mercurial allows sharing code and still linearizing history with rebase safely, so much less need for merges. I've always found pull requests to be only useful for the passing-by contribution. They are a pretty awful interface for anything else driven by GitHub internals more than anything else...

> Pull Requests were never going to happen with Mercurial

TBF, AIUI they're not, strictly speaking, happening with git either: They're an external addition, invented by GitHub or some such, and not actually part of git itself.

That is correct, but an important part of pull requests is that the pull request branch can be deleted afterwards.

How does that work; is it something technical built into it? Or do you mean just because after that one knows that it's incorporated upstream, so not needed as a separate entity any more? Because that would also go for a "pull request" by, say, e-mail or whatever.

we use it because it's blazing fast, stable and extremely versatile

I’d add another reason to that: we’re using Git because BitKeeper wasn’t free (as in beer) at the time for general purpose use. Had it been, we’d all be using BitKeeper instead.

Probably not. The free (as in speech) part of git is what made it usable for entities like google, Microsoft, github etc. If git had been released with the same license model of BitKeepr it NEVER would have taken off.

perhaps they were referring to the fact the kernel used to run bitkeeper as VCS but the licensing prohibited development

It’s not very fast when you account for all the time and productivity wasted on getting “unstuck” all the time.

I devoted some time to RTFM and actually learning how things work so I can't say that I run into this issue

Once you get over the initial learning curve you will not get stuck very often

True, a lot of people uses git without knowing how to use it, mainly because they do everything with a GUI and never learned how it works, and if something strange happens that can't be solved with the GUI they just delete the repo and clone it again.

At that point I say to these people, why you even bother with git? Just use what I call ".zip versioning", that is archive the source code an call it "project-vX.Y.Z.zip" and put it on the company fileserver.

Or better learn how to use git, and that means learning the command line and throwing out every gui (well, not all of them, for example I do commit and push/pull with VSCode, but when I have to do serious stuff like merging stuff I do it with the command line). To my experience GUI always cause problems than corrupt the history of the repository.

But he didn't write it. He started writing it in bash, and then (because he is Linus Torvalds), some very talented linux hackers jumped in to to help him. Just like with the kernel really. It was a tool written by extremely competent linux hackers for linux hackers, and that's why it is so successful.

I expect other programmers to learn and master tools they use 50 times per day. You should be getting more efficient, productive and make fewer mistakes with languages, frameworks and tools you use daily. If you prefer sourcetree, be it, but I expect you to use it efficiently and not make mistakes other people wouldn't do with git, zsh and ohmyzsh (which contains like 100s of handy shortcuts).

For me I’ve used visual git tools in the past and it ends up doing something unintended/unexpected. So now I only use the terminal commands. Perhaps the old git tools I’ve used have improved significantly though.

I prefer to rebase on the terminal also, but I reference Sourcetree when doing it.

> My job isn’t to use git, it’s to write specialist software.

This is true on so many other levels too. My job isn't to be an AWS expert, VIM master, Visual Studio ninja, Unix professor, et. al.

My job is to make the customer happy. That is it. If the customer is happy, my project managers are happy, the executives are happy, the investors are happy. When all of your bosses are happy, you can get away with absolute murder. No one gives you shit about anything. Production went down because you fucked up? No big deal - that was like the first time in 18 months we had any problems, and the customer can't even see these things through all the magical features get to play with day-to-day. Need to take the entire afternoon to play overwatch because [arbitrary fuck you reason abc]? No one cares as long as you didn't have a scheduled meeting. In this realm, your mind is free to explore side projects without fear of reproach or guilt-trip. Tasks are executed with confidence and calm. Innovations are more frequent and valuable. People are actually relaxing in their time off and enjoy working for their employer.

When the customer is pissed off, it is like entering into Doom Eternal as a non-player character. At every turn you begin to anticipate a heated conversation about missed target XYZ and incident ABC. Each ding of your outlook bumps your blood pressure by 20-30% before you even see the subject line. Your executives start taking damage from your customer's executives. Investors begin executing difficult queries regarding long-term viability. NO one is sleeping anymore. Side projects? Are you fucking kidding me? Not in this hell.

So, when someone in my organization starts giving me the run-around about [pedantic greybeard doctrine which adds 10x overhead to a process], and also has no business value to show for said run-around, I begin to shut things down pretty quickly. If you want to play nuclear release authorization simulator every time you need to check in source code, please do this on your own time. Even the most elite hacker rockstars like to use GUI tools so they can see what the fuck is going on without making their eyes bleed every 10-15 minutes due to terminal character display restrictions.

So putting aside your argument that I completely disagree with but a lot of people have already voiced my concerns.

> The guy who knows every command of git backwards is welcome to apply for a job managing a git repo or something if such a thing exists?

Yes, this is the job of a maintainer in fact. They exist in a variety of organisations but maybe not enough. The best example is the linux kernel. Developers are expected to maintain their own local tree. When it comes to contributing code to the kernel, the patches are sent in a standardised manner to a mailing list and a maintainer then handles dealing with branches, rebases and merges. This means that developers don't need to know any more git than they really want to learn, aside from how to use git-format-patch and git-send-email which are really quite simple tools with an incredibly vast number of tutorials out there explaining them.

This means that people who insist that it's "not their job" to learn git can achieve the requirements of "patches which build at every step and contain isolated step by step changes" using a GUI or doing something really stupid like copying the code aside, deleting and re-cloning the repository and then pasting and committing each step. It also means that people who actually know how to use git can get the job done in a fraction of the time.

It also means that a carpenter^Wdeveloper's insistence to not learn how to use a claw hammer^W^W^Wgit will not affect their fellow coworkers/cocontributors.

Absolutely. I can’t wait until something with better ux comes along and gets enough traction to make git a distant memory. I do not want to know the detailed inner workings of my VCS data model or 100 incongruent commands to make it work.

> My job isn’t to use git, it’s to write specialist software.

Part of the job is to know and understand the tools that you need to use to in order perform the duties as part of that job. Saying that it isn't your job to use git is like a surgeon saying it's not their job to learn how to tie sutures when closing up the surgical site after completing the operation.

> [I don't use git CLI so much any more] because I make less mistakes seeing the tree visually all the time.

I look at the tree visually so frequently it must be my most common command. In the CLI.

    log --graph --decorate --pretty=oneline --abbrev-commit
And then optionally adding whatever else, `--all` most frequently. (Obviously not writing it all out every time - with git config aliases, and actually `gitl` as a shell alias for that even. That's probably up there in my top.. 5? shell commands.)

GUIs work too of course. Just pointing out you don't have to abandon the CLI for a tree. There's fancier third-party tools than native git log that are still CLI even.

You don't even need git at that point. I don't understand why using git if you want a GUI... at this point, put the source code on the company fileserver and adopt "zip versioning", i.e. when you do a new release create an archive named "project-X.Y.z.zip" and archive it on the fileserver. If you need to work on another branch copy the source code directory. Why bother at this point?

I don't understand people that wants to use git but they want do to so with a GUI that abstract everything that git was created to address, and they limit themself to write some code, commit and push. You are not gaining any benefit in using git this way, you are only wasting time to me.

If you choose to adopt git, you learn how to use it, and so you learn the commands (it's not that much effort). In my experience GUI always created problems, especially if someone in a team uses a GUI that creates junk in the repository (like 100 useless merge commits created automatically for things that shouldn't really have been a merge that make git log unreadable...).

Also people that uses GUI typically when they have a problem that the GUI doesn't know how to solve (because they typically implement the basic things and if something goes wrong they can't help you) just deletes the whole repo and clones it again, or worse they try to fix it by pressing random buttons in the GUI and put the repo in a shitty state so another coworker that knows how to use git has to waste his time cleaning up the crap that the fantastic git GUI made.

And I'm not saying that you shouldn't 100% use GUIs. I use the one of VSCode for doing simple things like creating commits, switching branches, and stuff like that. For advanced features like merge, cherry pick, rebase, whatever I use the CLI, I find it more practical.

Commands are explicit and shareable. If you’ve mastered <ide> then good on you, but it makes you an island.

A couple of easily added aliases to .gitconfig and my CLI can do everything your GUI can do, in a portable way, and much easier and faster IMO.

Nothing to learn or even forget, either, as the CLI is actually the easier part of the job.

So, you do you, nothing wrong with that, but the CLI is here to stay.

Except for 99% of all git day to day tasks are done with like 7 commands.

Git commit

Git checkout

Git merge

Git pull

Git push

Git rebase

Git stash

I can’t remember I needed a command that wasn’t one of those and I exclusively use the cli.

I've used git for over a decade, and I can't think of anything new I've learned in the past 4 years.

And that last new thing was when git added worktree, which I don't actually use, but I learned about.

Contrast that with almost any other program....it's impressive.

It's funny but I forgot that Git restore was a new command, it only came in 2019 but I use it all the time.

I seem to use cherry-pick at least monthly, as well as log and diff.

I was gonna say cherry-pick is farily frequent for me. Also I seem to learn new variations once in a blue moon for common commands. E.g. recently I learned about the --cherry option for git-log and it changed my life.

>> My job isn’t to use git, it’s to write specialist software.

It's like a plumber complaining that his job isn't driving with a car and that he wants customers to pick him up or wait for him until he comes on foot or via public transport.

A fairer analogy is that GP is saying, "I don't want to use a van to bring my stuff, but prefer a pickup truck." From the customer's POV, it makes no difference.

I find the visual ones often harder to use but that's just me. Whatever works works.

Having been through two Perforce -> git transitions of medium sized repos with a few dozen people contributing and being the person with the most git knowledge in the group to be called in when people new to git mess things up: these GUI git clients are ok if you know what you are doing and what the consequences of checking various checkboxes are. They are not conducive to people learning how the tool git works and how to use it to solve real world problems. The command line is a great way to learn git and then fundamental understanding can be used to reverse engineer what GUIs do under the hood.

At the end, it comes down to a personal preference of what you're most comfortable with. Some will prefer to use GUIs, others will prefer the command line.

Personally, I really enjoy using both the command line and the Github app. The Github app is super simple and straight forward, its great for just committing (parts of) files. Anything more than that and I prefer using the command line for "direct control".

If you understand how git works, its data structure essentially, then its far easier to do anything with IDE/GUI instead of CLI. They are more intuitive and shorten the work and less prone to mistakes.

I recently tried to help someone onboard into a cloud project that requires git tunneling due to security policies.

While they had experience with their IDE of choice and git, they were ultimately unable to push any changes.

Wonder how many command line enthusiasts are using gitflow to make things even simpler than sourcetree.

Using git from cli is like driving a Ferrari in a road with 30km/h speed limit

For me, as a dentist, I used to use the dental drill, but now I trust my janitor to handle it, this way I make less mistakes myself

My job as a dentist isn't to use dental drill, it's to fix teeth in general. If I managed to fix a tooth and customer is happy, it doesn't matter whether I use drill myself or janitor does. Imagine having 100 complex things bouncing around your head and having to make that 101 when you forget the order of drill bits you need for a root canal.

The guy who knows dental drilling backwards is welcome to apply for a job managing dental drills or something if such a thing exists? But I could harp on the same way about his missing medical or braces-training skills.

It's more like getting the dental assistant to operate the autoclave.

Endless opportunity for analogies here. The gist is that you are delegating all sensitive versioning and versioning history management operations to a 3rd party with extremely limited capabilities, 3rd party you know nothing about (effectively a black box).

We thrive on abstractions, but unfortunately in case with versioning and git in particularly, GUI apps is a wrong one.

Your analogy is completely awful

The janitor knows nothing about dentistry. The git GUI knows plenty about it and the devs make it their job to know it too. A janitor is not an abstraction, he's a liability. If a GUI abstraction helps me get the job done faster, I really don't see the problem. Plus almost every one of them fully state the commands being used to perform every action and have logs you can parse. I used to use Sublime Merge and now use Fork and both have this

You are contradicting yourself and making my point for me.

janitor is an abstraction (you trust a janitor to operate with a professional tool for you) and you are completely right, git GUIs (just like a janitor) are a liability.

Your analogy is awful because there literally is a better analogue. A dental assistant. Someone who actually knows dentistry and can help with some of the simpler tasks to leave the dentist to concentrate on the actual surgery. You basically tried to fit a square hole in a round peg with your "analogy" to make your terrible point

If your janitor makes the client happy maybe he should retrain as a dentist?

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact