4 ms·

Deep knowledge of git is a sign of immaturity :) There are literally 10 commands one will ever need, which can be conveniently aliased to something more sane. K

by pacala 10y ago

Deep knowledge of git is a sign of immaturity :) There are literally 10 commands one will ever need, which can be conveniently aliased to something more sane. Keep the brain space for something that produces higher value add.

copperx 10y ago
Some day you will be caught in a corner case and you'll spend half a day learning about git's internals.
- alexbanks 10y ago
  Which I've always thought was a sign of mediocre software, but HN/Reddit seems to crucify those that criticize git. I think Git is like Javascript, it takes relatively little time to learn enough to get up and running, causing most people to forgoe learning all they'll actually need to be successful.
- pacala 10y ago
  I've been using git for 7 years now, never had the need to go deeper. Lately, I'm using github and pushing / saving my work every so often [kind of like CTRL + S in Windows Office in the '90s]. If something goes wrong, happy to yank the local git and start with a fresh clone from github :)
  - mixmastamyk 10y ago
    https://www.xkcd.com/1597/ https://www.xkcd.com/1597/
teej 10y ago
Ehh, I've been in situations where I screwed up so bad I had to find the "person who actually knows Git" come and save me. Let the kid go deep into whatever they want. Maybe having useful knowledge that others don't drives that person to like coding and makes it fun for them.
thesmallestcat 10y ago
You have to know how git works to use those commands competently...
- Koshkin 10y ago
  I am not sure if that would be a good thing to say about Git. The idea is that a well-designed system with a sane user interface should insulate the user as much as possible from the need to know the system's internals.
  - thesmallestcat 10y ago
    Not the internals, but what the commands are doing. What the index is, what a parent or child reference is, things like that are essential to using git effectively.
gregshap 10y ago
1) You never know what someone means by 'deep knowledge' 2) What works on a personal project, or microservice repo, might not scale well with many engineers doing overlapping work in the same codebase 3) consider that even if you are perfect, other people can make mistakes that introduce issues 4) 'advanced' techniques can make a complex version history more readable, which pays dividends by saving brain space in the future
barrkel 10y ago
I find thinking of git as a DAG of diffs, and branches as mutable references to DAG nodes, a simplifying conceptualization. I found git really easy to pick up and much, much simpler to learn and use than svn or cvs. Thinking of it this way, I know the solution to my code repo problems before I know the exact commands that perform the graph transitions. Because I have this mental model, I know the commands must exist in one form or another.
dasil003 10y ago
I disagree, git is my favorite VCS by far because of the power it gives to truly craft a record of ones development history. A finely crafted development history pays major dividends as a project ages. I just got a thank you note for commit messages I wrote 4 years ago on a previous project. A lot of devs see commit messages and rebasing as useless pedantry, but once you start to take it seriously it only takes a little bit of extra time, and it provides so much future benefit via git-bisect and general spelunkability. I also think it's worth investing more time in a tool based on its longevity in ones workload. In that regard I put git at the top of the food chain, as I expect to use it even longer than Linux, for example in my case: Git > Linux > Vim > Ruby/Python > OS X / GUI tools. A side effect of being this good at git is the ability to bail out your colleagues when they royally fuck up a merge or rebase.
- pacala 10y ago
  For development history, we're using good PRs and good PR comments on GitHub. We've started using GitHub squash commits, but not enough long term usage to say how reliable it is. No need to manually rebase or fix someone else's broken rebase. The workflow is directly inspired by git-as-a-wrapper-around-Perforce used at Google.
  - dasil003 10y ago
    I'm a big fan of PRs/comments on GitHub as well (although they do raise some data ownership issues). Squashed commits are interesting, but not something I've used personally in GitHub. I think squashing, especially automatically, has big tradeoffs. It's nice to have a cohesive unit of change in a single commit, but if your mergeable features have a lot of moving parts it may be too much information in one giant blob, losing valuable history. There are certain things I like to be in individual commits, like for instance, DB migrations in Rails or Django, or Gemfile/Gemfile.lock upgrades. Having these in separate commits allows for easier conflict resolution later, and are also a nice granularity for practices like zero-downtime continuous deployment where you need to have multi-phase deploy of migrations (ie. phase 1: deploy migrations that add fields, phase 2: deploy code that requires new fields, phase 3: remove fields required by legacy code). Maybe in a large team with a large volume of PRs then squashing by default is preferred so you can make sense of a fast-moving history, but given that it's so easy to squash selectively with `git rebase -i` that is my preferred method, at least for the team I'm on now.

by pacala 10y ago

copperx 10y ago

Some day you will be caught in a corner case and you'll spend half a day learning about git's internals.

alexbanks 10y ago
Which I've always thought was a sign of mediocre software, but HN/Reddit seems to crucify those that criticize git. I think Git is like Javascript, it takes relatively little time to learn enough to get up and running, causing most people to forgoe learning all they'll actually need to be successful.
pacala 10y ago
I've been using git for 7 years now, never had the need to go deeper. Lately, I'm using github and pushing / saving my work every so often [kind of like CTRL + S in Windows Office in the '90s]. If something goes wrong, happy to yank the local git and start with a fresh clone from github :)
- mixmastamyk 10y ago
  https://www.xkcd.com/1597/ https://www.xkcd.com/1597/

teej 10y ago

Ehh, I've been in situations where I screwed up so bad I had to find the "person who actually knows Git" come and save me. Let the kid go deep into whatever they want. Maybe having useful knowledge that others don't drives that person to like coding and makes it fun for them.

thesmallestcat 10y ago

You have to know how git works to use those commands competently...

Koshkin 10y ago
I am not sure if that would be a good thing to say about Git. The idea is that a well-designed system with a sane user interface should insulate the user as much as possible from the need to know the system's internals.
- thesmallestcat 10y ago
  Not the internals, but what the commands are doing. What the index is, what a parent or child reference is, things like that are essential to using git effectively.

gregshap 10y ago

1) You never know what someone means by 'deep knowledge' 2) What works on a personal project, or microservice repo, might not scale well with many engineers doing overlapping work in the same codebase 3) consider that even if you are perfect, other people can make mistakes that introduce issues 4) 'advanced' techniques can make a complex version history more readable, which pays dividends by saving brain space in the future

barrkel 10y ago

I find thinking of git as a DAG of diffs, and branches as mutable references to DAG nodes, a simplifying conceptualization. I found git really easy to pick up and much, much simpler to learn and use than svn or cvs. Thinking of it this way, I know the solution to my code repo problems before I know the exact commands that perform the graph transitions. Because I have this mental model, I know the commands must exist in one form or another.

dasil003 10y ago

I disagree, git is my favorite VCS by far because of the power it gives to truly craft a record of ones development history. A finely crafted development history pays major dividends as a project ages. I just got a thank you note for commit messages I wrote 4 years ago on a previous project. A lot of devs see commit messages and rebasing as useless pedantry, but once you start to take it seriously it only takes a little bit of extra time, and it provides so much future benefit via git-bisect and general spelunkability. I also think it's worth investing more time in a tool based on its longevity in ones workload. In that regard I put git at the top of the food chain, as I expect to use it even longer than Linux, for example in my case: Git > Linux > Vim > Ruby/Python > OS X / GUI tools. A side effect of being this good at git is the ability to bail out your colleagues when they royally fuck up a merge or rebase.

pacala 10y ago
For development history, we're using good PRs and good PR comments on GitHub. We've started using GitHub squash commits, but not enough long term usage to say how reliable it is. No need to manually rebase or fix someone else's broken rebase. The workflow is directly inspired by git-as-a-wrapper-around-Perforce used at Google.
- dasil003 10y ago
  I'm a big fan of PRs/comments on GitHub as well (although they do raise some data ownership issues). Squashed commits are interesting, but not something I've used personally in GitHub. I think squashing, especially automatically, has big tradeoffs. It's nice to have a cohesive unit of change in a single commit, but if your mergeable features have a lot of moving parts it may be too much information in one giant blob, losing valuable history. There are certain things I like to be in individual commits, like for instance, DB migrations in Rails or Django, or Gemfile/Gemfile.lock upgrades. Having these in separate commits allows for easier conflict resolution later, and are also a nice granularity for practices like zero-downtime continuous deployment where you need to have multi-phase deploy of migrations (ie. phase 1: deploy migrations that add fields, phase 2: deploy code that requires new fields, phase 3: remove fields required by legacy code). Maybe in a large team with a large volume of PRs then squashing by default is preferred so you can make sense of a fast-moving history, but given that it's so easy to squash selectively with `git rebase -i` that is my preferred method, at least for the team I'm on now.