More Productive Git • Hacker News Board

Re: More Productive Git

#111

Post by duncan-donuts » Sat, May 25, 2019, 2:01 AM UTC

albertgoeswoof wrote: post #98

finnthehuman wrote: post #97

Earlier quoted context omitted.

I, on the other hand, see these threads and wonder how arrogant and fraudulent our industry is when programmers have to pat eachother on the back and say the problem is git. Git is a tool for creating and navigating a directed acyclic graph of revisions. It’s fine to chuckle and make fun about how esoteric that sounds, but at the same time I expect people that work on my team to rise to the challenge of proving that…

This is self defeating, if git was easier to use your team members could take that extra day and learn something more valuable. Just because something is hard it doesn’t mean it’s worth doing.

How much of git is actually that hard though? There are definitely some extremely dark corners in git, but most people really only need 4 commands (add, commit, push, pull) to get started. Once you start needing to do more you start to incrementally adopt features. I’m not trying to trivialize git because it’s obviously complicated. I’m not sure I accept that someone can’t be productive with git in a reasonably short amount of time.

Re: More Productive Git

#112

Post by chiefalchemist » Sat, May 25, 2019, 2:05 AM UTC

finnthehuman wrote: post #97

chiefalchemist wrote: post #31

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

I, on the other hand, see these threads and wonder how arrogant and fraudulent our industry is when programmers have to pat eachother on the back and say the problem is git. Git is a tool for creating and navigating a directed acyclic graph of revisions. It’s fine to chuckle and make fun about how esoteric that sounds, but at the same time I expect people that work on my team to rise to the challenge of proving that…

> "Git is a tool for creating and navigating a directed acyclic graph of revisions. It’s fine to chuckle and make fun about how esoteric that sounds, but at the same time I expect people that work on my team to rise to the challenge of proving that they occasionally attended data structures and algorithms class."

And those can (read:should) have a visual representation, yes? Why are we still typing archaic/cryptic commands - read: wasting brain cycles that could be better spent - for what are ultimately manipulation of something best represented visually?

It's time to move on. I'm sure someone will fax you when the time comes. Hopefully, you can keep up :)

Re: More Productive Git

#113

Post by bamboozled » Sat, May 25, 2019, 2:07 AM UTC

finnthehuman wrote: post #97

chiefalchemist wrote: post #31

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

I, on the other hand, see these threads and wonder how arrogant and fraudulent our industry is when programmers have to pat eachother on the back and say the problem is git. Git is a tool for creating and navigating a directed acyclic graph of revisions. It’s fine to chuckle and make fun about how esoteric that sounds, but at the same time I expect people that work on my team to rise to the challenge of proving that…

I have to say I thought something similar to your sentiment.

When I interview people for software engineering roles in 2019 who haven't bother to learn Git or struggle to understand it's use-case, basics and relatively simple to use interface I can quite easily use this to make some important assumptions about the candidate. The most important being that maybe software engineering isn't the right career choice for that person, at least not yet.

Is there room for improvement? Sure, but let's make sure where ever we go, it's to a better place, not a worse one.

Re: More Productive Git

#114

Post by duncan-donuts » Sat, May 25, 2019, 2:07 AM UTC

chiefalchemist wrote: post #73

alkonaut wrote: post #51

Earlier quoted context omitted.

I’m about to roll out git to a team of 30 windows devs of the kind that do NOT like using command line (which is a perfectly sensible thing on Windows I should add, it’s rarely needed there and most command line tools including the shell itself sucks). I assure you they will find it complicated. I’ll insist we switch to git but it’s still going to be an uphill battle. Some will surely struggle also a year from now.

Windows user here, tho' I don't think that has much to do with my analysis/opinion. Ultimately, to me, the dev via Git is doing something that is best explained visually. It seems counter-intuitive to type commands for what is visual, at the very leaat it's unnerving (as if we don't have enough friction and stress in our day already). To me, Git via the command line, constitutes industry "jargon". It's used - wrongly…

What about using git plus a shell make you an elitist? What if I used something else from a shell that isn’t as negatively perceived as git? I’ve used git with a ui (early on) and a shell (later) and I don’t understand what makes it elitist. Figure out what tools make you the most productive. If vim makes you more productive, great. If a full blown IDE makes you more productive, great. I don’t understand the mindset around being critical of someone doing something in a way that works for them.

Re: More Productive Git

#115

Post by bamboozled » Sat, May 25, 2019, 2:13 AM UTC

chiefalchemist wrote: post #112

finnthehuman wrote: post #97

Earlier quoted context omitted.

I, on the other hand, see these threads and wonder how arrogant and fraudulent our industry is when programmers have to pat eachother on the back and say the problem is git. Git is a tool for creating and navigating a directed acyclic graph of revisions. It’s fine to chuckle and make fun about how esoteric that sounds, but at the same time I expect people that work on my team to rise to the challenge of proving that…

> "Git is a tool for creating and navigating a directed acyclic graph of revisions. It’s fine to chuckle and make fun about how esoteric that sounds, but at the same time I expect people that work on my team to rise to the challenge of proving that they occasionally attended data structures and algorithms class." And those can (read:should) have a visual representation, yes? Why are we still typing archaic/cryptic co…

There are visual tools for git though, so what's the problem?

- Gitk

- Tower for OS X

- Github

Besides, some people enjoy using CLI tools the obvious reason that they're simple to use and can be used programmatically with minimal overhead.

Re: More Productive Git

#116

Post by sandov » Sat, May 25, 2019, 2:24 AM UTC

Why does the article link to the version 1 of the Pro git book instead of the v2?

https://git-scm.com/book/en/v2/

Re: More Productive Git

#117

Post by wyclif » Sat, May 25, 2019, 2:33 AM UTC

bamboozled wrote: post #113

finnthehuman wrote: post #97

Earlier quoted context omitted.

I, on the other hand, see these threads and wonder how arrogant and fraudulent our industry is when programmers have to pat eachother on the back and say the problem is git. Git is a tool for creating and navigating a directed acyclic graph of revisions. It’s fine to chuckle and make fun about how esoteric that sounds, but at the same time I expect people that work on my team to rise to the challenge of proving that…

I have to say I thought something similar to your sentiment. When I interview people for software engineering roles in 2019 who haven't bother to learn Git or struggle to understand it's use-case, basics and relatively simple to use interface I can quite easily use this to make some important assumptions about the candidate. The most important being that maybe software engineering isn't the right career choice for th…

Another thing about this is the assumption that a candidate has to be a Git ninja. If a dev can't read the Git documentation and narrow down the most important use cases, then it should definitely trigger a red flag. You don't need all the features to be productive. Unless you are an edge case, you can probably do most of what you need to get done with these six commands:

branch checkout add commit pull push

Reading and understanding the documentation for those six core commands isn't a big investment, and it will pay off if you're doing software or documentation development.

Re: More Productive Git

#118

Post by anyonecancode » Sat, May 25, 2019, 2:35 AM UTC

chiefalchemist wrote: post #31

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

I'm one of those that likes git, finds it decently easy to use, and is much more productive because of it. But I do think there's merit to complaints about git. There's a wide range of experience, skill sets, and programming styles in our industry, and overall this isn't a problem as people can pick up the tools that work best for them. Look at text editors, for instance -- some people use sublime, others intellij, others vim, others emacs, etc. But for version control, there's really only git now. I'm personally a vim user, but I think it would be strange to insist that everyone must use vim.

The text editor analogy falls short in that version control has to be used by the entire team whereas a text editor only has to work for an individual developer. So, I can see the argument that the standard version control tool should be a little more intuitive. I think one challenge though is that, in my experience, it's not even the command line so much as some basic concepts around vcs that people struggle with, so "more intuitive tool" is a hard challenge I think.

Re: More Productive Git

#119

Post by wyclif » Sat, May 25, 2019, 2:36 AM UTC

My pro tip for 'more productive Git':

Read the Git documentation thoroughly. Most people don't, and then wonder why they have no idea what's going on when a project they're put on uses Git for version control.

Re: More Productive Git

#120

Post by blknmild » Sat, May 25, 2019, 2:53 AM UTC

I got shamed a few times in a new role awhile back in part [imo] because it was assumed I was 1000% git-fluent. The way I’ve started to view svc ticks is similar to how I view grammar knotsies. In the end the idea is to communicate, not to make other people feel like dunces.