5 ms·

That's the blog post I always wanted to write. So many people spend little to no time to actually learn Git, because "it's just a tool to help you doing your "r

That's the blog post I always wanted to write. So many people spend little to no time to actually learn Git, because "it's just a tool to help you doing your "real" work" (=coding) . Or because "Git is too difficult/confusing/broken". Or because "I don't need anything except commit/push/pull". I find those arguments somewhat true, but I still feel that people are missing out when they don't learn a tool they use daily properly. In best case, it makes them less efficient. In worst case, they get into "unsolvable" issues and/or pollute the Git history with useless commits, making blames more troublesome for the whole team.

jimbob45 5y ago
It is just a tool to help you do your real work and famously gets in the way. You use SVN and it covers 99% of use cases much more simply than Git manages.
- 8372049 5y ago
  When you write things like that, you come across as trolling. Their point wasn't git vs. another tool, their point was the importance of knowing intricate details about your tools in certain circumstances. If SVN is wonderful for you: Great! But that's not really relevant to the issue of using git effectively.
- sagonar 5y ago
  If svn covers 99% of your use cases, then you need more experience with distributed version control systems. Able to commit locally, examine changes work with them and then push is a something you might not need or require if you think about version system like SVN. But if you have learned Git or Mercurial or some other distributed system you would never go back to svn.
  - maccard 5y ago
    I have lots of experience with git (5 years of usage, 1 of those years was writing tooling in and around git) and pretty much the same experience with perforce, and I much prefer the centralized model of perforce to all the extra fun that comes with git
  - alex_smart 5y ago
    I was molded in "git" way of thinking about version control, but I was forced to use SVN in a job. Not having local branches is not that bad. Like, people find ways to work around it: e.g. maintaining changesets in patch-files, or just keep multiple different checkouts.
- BossingAround 5y ago
  I've never used SVN, but I assume that because git uniformly won as the VCS tool, it suits most people better than SVN..?
  - petepete 5y ago
    The reason git won was in part due to the success of GitHub. It was the first code sharing platform that wasn't a crap. Once open source projects started moving to it from older platforms (Sourceforge, Trac, etc), developers who might not have cared so much about VCS flavours followed.
    - nayuki 5y ago
      In turn, I think GitHub won because of Git. Centralized version control systems like Subversion are oriented around "committer permissions". Giving someone commit access incurs friction (waiting for a human to respond) and risk (potentially unwanted changes). None of the old platforms like SourceForge implemented the concept of cloning a whole repository. Even if you made your own clone (manually or otherwise), what good would that do? Your copy would diverge from the upstream and can never be automatically reconciled. You would be forever doomed to sending patches to upstream, and calculating diffs from upstream to apply to your repo. Or just replacing your clone with the upstream's history after your patch gets accepted. Git natively supports multiple asynchronous repos representing the same "project" because its history is designed around a directed acyclic graph (DAG) structure. You don't need the upstream repo's permission to make your own clone and commit some changes. After you diverge from the upstream, if you solicit them with your branch and they accept, then both of you can converge once again - whereas this is impossible in a linear history model like SVN.
- deckard1 5y ago
  that's just laughable considering SVN needs a central repo to work and I can just do "git init ." to create a git repo in any directory at any time I want and is entirely self-contained. Once an SVN user discovers the magic of a staging area, stashes, or "git add -p" I don't know how they could claim SVN does anything better. All I remember from those days was how slow everything in SVN was. It felt like every command was backed by some horrible O(n^2) operation or really slow network connection. git isn't hard. FFS, we shouldn't keep seeing these posts hitting HN every week. iptables? That's tough. DNS? No thanks. Managing package.json and keeping an app up-to-date? Git is nothing in comparison to the real challenges I face everyday.
  - Buttons840 5y ago
    Early in my career I was a junior developer on a team using SVN. I knew git and used a git plugin that let it work with SVN. I would often talk about various branches and things I was doing locally in my repository and the other developers would get concerned, because making a branch is SVN is a big deal, and here I am, it seems, making tons of branches. It was fun because when I would finally upstream my work, it would dump a dozen commits into the SVN history all within the same second. It was kind of nice having the linear history forced by SVN though.
  - jimbob45 5y ago
    >Once an SVN user discovers the magic of a staging area You can already do that with TortoiseSVN or just through the cline >stashes SVN uses shelves >git isn't hard This feels like the "lisp is magic" argument that no one can seem to prove, despite how universal its proponents claim the law to be.
  - tempodox 5y ago
    > that's just laughable considering SVN needs a central repo to work… Do you use GitHub, GitLab, Bitbucket, gitea, ...? There's your central repo. If nothing else, it represents the “backup” facet of using an SCM.
  - recursive 5y ago
    I've been using the staging area for a long time. It only makes me wish I could turn it off.

jimbob45 5y ago

It is just a tool to help you do your real work and famously gets in the way. You use SVN and it covers 99% of use cases much more simply than Git manages.

8372049 5y ago
When you write things like that, you come across as trolling. Their point wasn't git vs. another tool, their point was the importance of knowing intricate details about your tools in certain circumstances. If SVN is wonderful for you: Great! But that's not really relevant to the issue of using git effectively.
sagonar 5y ago
If svn covers 99% of your use cases, then you need more experience with distributed version control systems. Able to commit locally, examine changes work with them and then push is a something you might not need or require if you think about version system like SVN. But if you have learned Git or Mercurial or some other distributed system you would never go back to svn.
- maccard 5y ago
  I have lots of experience with git (5 years of usage, 1 of those years was writing tooling in and around git) and pretty much the same experience with perforce, and I much prefer the centralized model of perforce to all the extra fun that comes with git
- alex_smart 5y ago
  I was molded in "git" way of thinking about version control, but I was forced to use SVN in a job. Not having local branches is not that bad. Like, people find ways to work around it: e.g. maintaining changesets in patch-files, or just keep multiple different checkouts.
BossingAround 5y ago
I've never used SVN, but I assume that because git uniformly won as the VCS tool, it suits most people better than SVN..?
- petepete 5y ago
  The reason git won was in part due to the success of GitHub. It was the first code sharing platform that wasn't a crap. Once open source projects started moving to it from older platforms (Sourceforge, Trac, etc), developers who might not have cared so much about VCS flavours followed.
  - nayuki 5y ago
    In turn, I think GitHub won because of Git. Centralized version control systems like Subversion are oriented around "committer permissions". Giving someone commit access incurs friction (waiting for a human to respond) and risk (potentially unwanted changes). None of the old platforms like SourceForge implemented the concept of cloning a whole repository. Even if you made your own clone (manually or otherwise), what good would that do? Your copy would diverge from the upstream and can never be automatically reconciled. You would be forever doomed to sending patches to upstream, and calculating diffs from upstream to apply to your repo. Or just replacing your clone with the upstream's history after your patch gets accepted. Git natively supports multiple asynchronous repos representing the same "project" because its history is designed around a directed acyclic graph (DAG) structure. You don't need the upstream repo's permission to make your own clone and commit some changes. After you diverge from the upstream, if you solicit them with your branch and they accept, then both of you can converge once again - whereas this is impossible in a linear history model like SVN.
deckard1 5y ago
that's just laughable considering SVN needs a central repo to work and I can just do "git init ." to create a git repo in any directory at any time I want and is entirely self-contained. Once an SVN user discovers the magic of a staging area, stashes, or "git add -p" I don't know how they could claim SVN does anything better. All I remember from those days was how slow everything in SVN was. It felt like every command was backed by some horrible O(n^2) operation or really slow network connection. git isn't hard. FFS, we shouldn't keep seeing these posts hitting HN every week. iptables? That's tough. DNS? No thanks. Managing package.json and keeping an app up-to-date? Git is nothing in comparison to the real challenges I face everyday.
- Buttons840 5y ago
  Early in my career I was a junior developer on a team using SVN. I knew git and used a git plugin that let it work with SVN. I would often talk about various branches and things I was doing locally in my repository and the other developers would get concerned, because making a branch is SVN is a big deal, and here I am, it seems, making tons of branches. It was fun because when I would finally upstream my work, it would dump a dozen commits into the SVN history all within the same second. It was kind of nice having the linear history forced by SVN though.
- jimbob45 5y ago
  >Once an SVN user discovers the magic of a staging area You can already do that with TortoiseSVN or just through the cline >stashes SVN uses shelves >git isn't hard This feels like the "lisp is magic" argument that no one can seem to prove, despite how universal its proponents claim the law to be.
- tempodox 5y ago
  > that's just laughable considering SVN needs a central repo to work… Do you use GitHub, GitLab, Bitbucket, gitea, ...? There's your central repo. If nothing else, it represents the “backup” facet of using an SCM.
- recursive 5y ago
  I've been using the staging area for a long time. It only makes me wish I could turn it off.