5 ms·

People saying they wouldn't use git don't know git. I admit it does take investment to learn but once you are over the hump it is insanely easy and useful (yes

People saying they wouldn't use git don't know git. I admit it does take investment to learn but once you are over the hump it is insanely easy and useful (yes even easier than rsync and 10x more useful). Especially when you consider that using rsync precludes your from collaborating even with one other person which is crazy easy if you use github (for example). People not using git: get over the hump, it is worth it, even on little side projects.

87 8y ago
Recently I've seen a friend collaborate with teammate by sending each other zips. Using Skype! And as far as I can tell they're pretty productive. Dedication and hard work generally tends to produce results regardless. When you use git you still need to use it right. How many times have you cloned a repo just to find out it won't build/run/compile without help? Personally, with small projects - more often than not. And I have a habit of asking if they do know for a fact it's going to build without assistance. It doesn't help. I like git as a glorified change-log, slack commit messages especially. I try to keep everything tidy and build-able as much as anybody. But I'll still give people an archive (with .git included). And ironically this keeps git tidier as you don't obsess over whether or not to commit certain things.
- existencebox 8y ago
  When I first started learning how to program, I didn't know git existed. When I eventually learned a year later, I was already well acquainted with sending myself zips by email, and using email as "history". Git was quite scary to me at the time, (merges and reset/revert as I recall) so for a good year or two more I just kept using emails. It certainly wasn't pretty, but it required almost 0 mental cycles, worked without question, and actually gave some really nice features comparatively. (searching for a "commit" using complex queries) We were eventually forced to use git/hg/svn for some courses over that time, so I became comfortable out of necessity and now vc for anything serious; had to unfortunately even use TFS for a while. (guilty secret, for many toy projects, I absolutely just have a folder on my fileserver and rely on its backup/replication, zipping the folder if I want to "snapshot".)
  - tonyarkles 8y ago
    I really learned to appreciate VC when growing to a team project. Know what's even scarier than SVN or Git merges? Trying to merge zip files...
    - fragmede 8y ago
      That's pretty easy. All you have to do is extract the first zip, go into the directory, run `git init; git add -a; git commit -m first` then unzip the second one and run... Hey wait a second.
      - danieldk 8y ago
        diff -ruN dir1 dir2 Use your favorite merge tool for changed files (like in git). (Of course, proper VCS wins any day.)
  - i_made_a_booboo 8y ago
    Please don't try to sell the world on working this way. It's just terrible and lazy. You can learn enough git to use it productively in 5 commands. It's not even difficult.
    - existencebox 8y ago
      I think you've entirely misread my post. I was giving a "cute" story concurring with the author that you can manage to be productive with duct tape and spit, and that it can be a learning period when understanding proper tooling, especially if one is coming in without any real oversight or mentorship at first; if you're reading this thread on HN you're probably far more exposed to CS than I was at that point. There's no "selling anyone" on anything. I would however frankly say that I think the inability to recognize how intimidating git can be to an uninitiated was the _reason_ it took so long for me and many of my classmates; (this was over a decade ago, and I've been using vc professionally the entire interim) certainly far more damaging than anything you accuse me of propagandizing; It was extremely frustrating and dismissive to constantly be told by more experienced programmers that I should feel far more confident than I was about a tool that in hindsight, I don't look askew at myself for finding some aspects of unintuitive, and I'm a constant user now. And, while I'm on this tirade, if you're addressing "working this way" as a negative to put unimportant toy projects on a heavily replicated and backed up server, I think you and I have different priorities in how we use our time.
Mc_Big_G 8y ago
WTF? Seriously? The latest thing is to NOT use git? haha We just jumped the shark.
bch 8y ago
>> ...with no care in the world about version control (rsync does most of what I need: backups), and deployed to servers by manual SCP... > People saying they wouldn't use git don't know git. A few things: * to the grandparent, rsync is awesome, but comparing it to version control is comparing apples to orangutans. * to the parent, version control != git, and there are easy arguments to be made against git * distributed version control is one of the greatest things to emerge in the last 20 years. If git isn’t your thing, check out (haha) fossil or mercurial Edit: some reference reading. If it’s not already integral to your workflow, get familiar with distributed source control - you’re unlikely to regret it: https://en.wikipedia.org/wiki/Distributed_version_control https://en.wikipedia.org/wiki/Distributed_version_control
- rahulroy9202 8y ago
  What are some arguments to be made against git?
na85 8y ago
Git's UX is horrible for people who don't know git, i.e. git beginners. All the documentation and error messages are written as if the user is already intricately familiar with the inner workings of git. As a result, it's very hard to learn because you don't know what you're about to do without hours of googling cryptic error messages. Perfect example that happened to me today: $ git push fatal: The current branch insert_branchname_here has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin insert_branchname_here What does it mean to "set the remote as upstream"? That phrase makes no sense to me. Is that going to overwrite master on origin? I have no idea, but I'll be damned if I am going to hit enter and risk overwriting my upstream branch, so I Ctrl+C out of there and had to read a bunch of awful reference docs posing as a tutorial. Git is just plain terrible in almost every way. It just happens to be less terrible for certain workflows than CVS/SVN/mercurial/whatever.
- tjr225 8y ago
  I don't know. I've gotten away with using pretty much the commands in this guide for almost three years now (professionally): https://rogerdudler.github.io/git-guide/ https://rogerdudler.github.io/git-guide/ - I even structure my orgs internal git documentation around these commands for newbies (with sources of course). There are times when you need to troubleshoot a few things but most of the time you can just delete your local repo and reclone it - easy peazy. One of the other great things about git is that even if you do somehow fuck something up upstream it is really easy to get it back. Heck I think git is pretty awesome.
- zdragnar 8y ago
  The command failed, with a clear error message, and a direct instruction on exactly how to redolve it. That is good UX. Your example boils down to not knowing the word "upstream". I would argue that is table stakes domain knowledge for decentralized version control, and is trivially easy to search for. That does not make bad UX. Good UX does not eliminate the need for domain knowledge, it eliminates incidental complexity from a user's task, and one could argue makes a tool pleasant to use. I don't disagree that there are rough edges to git (the debate over merge vs rebase is a glaring example), but "just plain terrible in every way" is gross hyperbole.
nullpunkt 8y ago
sorry but it's not easier to use than rsync. it's a false assumption
greenhatman 8y ago
Even if you only use Git for save points, it's game changing. I honestly can't imagine working without it. I'd be too afraid to change anything, in case I break it.
p0nce 8y ago
Git is nothing special, sometimes SVN is a better choice.
- bad_user 8y ago
  No, SVN is never the better choice, not even if you’re solo. Learn some Git and stick to it, it’s a one day job. And most of the time you’ll use these commands git clone git add git commit git pull git push git checkout git branch git log You can do some Googling for how to use them and contrary to popular opinion it’s really not much to it. Mercurial users are moaning about it, but Git has a better track record of maintaining backwards compatibility. The advantage over SVN is in working with local or personal repositories. And forks of other projects in your local / personal repos, which happen all the time; heck, you will want to work with forks of your own repos for experiments; post-Git of course, b/c doing that with SVN is a pain in the ass.
  - p0nce 8y ago
    I don't know why you assume I don't know git.
    - bad_user 8y ago
      When I said "you" above, I meant the royal "you", this being a public message.

87 8y ago

Recently I've seen a friend collaborate with teammate by sending each other zips. Using Skype! And as far as I can tell they're pretty productive. Dedication and hard work generally tends to produce results regardless. When you use git you still need to use it right. How many times have you cloned a repo just to find out it won't build/run/compile without help? Personally, with small projects - more often than not. And I have a habit of asking if they do know for a fact it's going to build without assistance. It doesn't help. I like git as a glorified change-log, slack commit messages especially. I try to keep everything tidy and build-able as much as anybody. But I'll still give people an archive (with .git included). And ironically this keeps git tidier as you don't obsess over whether or not to commit certain things.

existencebox 8y ago
When I first started learning how to program, I didn't know git existed. When I eventually learned a year later, I was already well acquainted with sending myself zips by email, and using email as "history". Git was quite scary to me at the time, (merges and reset/revert as I recall) so for a good year or two more I just kept using emails. It certainly wasn't pretty, but it required almost 0 mental cycles, worked without question, and actually gave some really nice features comparatively. (searching for a "commit" using complex queries) We were eventually forced to use git/hg/svn for some courses over that time, so I became comfortable out of necessity and now vc for anything serious; had to unfortunately even use TFS for a while. (guilty secret, for many toy projects, I absolutely just have a folder on my fileserver and rely on its backup/replication, zipping the folder if I want to "snapshot".)
- tonyarkles 8y ago
  I really learned to appreciate VC when growing to a team project. Know what's even scarier than SVN or Git merges? Trying to merge zip files...
  - fragmede 8y ago
    That's pretty easy. All you have to do is extract the first zip, go into the directory, run `git init; git add -a; git commit -m first` then unzip the second one and run... Hey wait a second.
    - danieldk 8y ago
      diff -ruN dir1 dir2 Use your favorite merge tool for changed files (like in git). (Of course, proper VCS wins any day.)
- i_made_a_booboo 8y ago
  Please don't try to sell the world on working this way. It's just terrible and lazy. You can learn enough git to use it productively in 5 commands. It's not even difficult.
  - existencebox 8y ago
    I think you've entirely misread my post. I was giving a "cute" story concurring with the author that you can manage to be productive with duct tape and spit, and that it can be a learning period when understanding proper tooling, especially if one is coming in without any real oversight or mentorship at first; if you're reading this thread on HN you're probably far more exposed to CS than I was at that point. There's no "selling anyone" on anything. I would however frankly say that I think the inability to recognize how intimidating git can be to an uninitiated was the _reason_ it took so long for me and many of my classmates; (this was over a decade ago, and I've been using vc professionally the entire interim) certainly far more damaging than anything you accuse me of propagandizing; It was extremely frustrating and dismissive to constantly be told by more experienced programmers that I should feel far more confident than I was about a tool that in hindsight, I don't look askew at myself for finding some aspects of unintuitive, and I'm a constant user now. And, while I'm on this tirade, if you're addressing "working this way" as a negative to put unimportant toy projects on a heavily replicated and backed up server, I think you and I have different priorities in how we use our time.

Mc_Big_G 8y ago

WTF? Seriously? The latest thing is to NOT use git? haha We just jumped the shark.

bch 8y ago

>> ...with no care in the world about version control (rsync does most of what I need: backups), and deployed to servers by manual SCP... > People saying they wouldn't use git don't know git. A few things: * to the grandparent, rsync is awesome, but comparing it to version control is comparing apples to orangutans. * to the parent, version control != git, and there are easy arguments to be made against git * distributed version control is one of the greatest things to emerge in the last 20 years. If git isn’t your thing, check out (haha) fossil or mercurial Edit: some reference reading. If it’s not already integral to your workflow, get familiar with distributed source control - you’re unlikely to regret it: https://en.wikipedia.org/wiki/Distributed_version_control https://en.wikipedia.org/wiki/Distributed_version_control

rahulroy9202 8y ago
What are some arguments to be made against git?

na85 8y ago

Git's UX is horrible for people who don't know git, i.e. git beginners. All the documentation and error messages are written as if the user is already intricately familiar with the inner workings of git. As a result, it's very hard to learn because you don't know what you're about to do without hours of googling cryptic error messages. Perfect example that happened to me today: $ git push fatal: The current branch insert_branchname_here has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin insert_branchname_here What does it mean to "set the remote as upstream"? That phrase makes no sense to me. Is that going to overwrite master on origin? I have no idea, but I'll be damned if I am going to hit enter and risk overwriting my upstream branch, so I Ctrl+C out of there and had to read a bunch of awful reference docs posing as a tutorial. Git is just plain terrible in almost every way. It just happens to be less terrible for certain workflows than CVS/SVN/mercurial/whatever.

tjr225 8y ago
I don't know. I've gotten away with using pretty much the commands in this guide for almost three years now (professionally): https://rogerdudler.github.io/git-guide/ https://rogerdudler.github.io/git-guide/ - I even structure my orgs internal git documentation around these commands for newbies (with sources of course). There are times when you need to troubleshoot a few things but most of the time you can just delete your local repo and reclone it - easy peazy. One of the other great things about git is that even if you do somehow fuck something up upstream it is really easy to get it back. Heck I think git is pretty awesome.
zdragnar 8y ago
The command failed, with a clear error message, and a direct instruction on exactly how to redolve it. That is good UX. Your example boils down to not knowing the word "upstream". I would argue that is table stakes domain knowledge for decentralized version control, and is trivially easy to search for. That does not make bad UX. Good UX does not eliminate the need for domain knowledge, it eliminates incidental complexity from a user's task, and one could argue makes a tool pleasant to use. I don't disagree that there are rough edges to git (the debate over merge vs rebase is a glaring example), but "just plain terrible in every way" is gross hyperbole.

nullpunkt 8y ago

sorry but it's not easier to use than rsync. it's a false assumption

greenhatman 8y ago

Even if you only use Git for save points, it's game changing. I honestly can't imagine working without it. I'd be too afraid to change anything, in case I break it.

p0nce 8y ago

Git is nothing special, sometimes SVN is a better choice.

bad_user 8y ago
No, SVN is never the better choice, not even if you’re solo. Learn some Git and stick to it, it’s a one day job. And most of the time you’ll use these commands git clone git add git commit git pull git push git checkout git branch git log You can do some Googling for how to use them and contrary to popular opinion it’s really not much to it. Mercurial users are moaning about it, but Git has a better track record of maintaining backwards compatibility. The advantage over SVN is in working with local or personal repositories. And forks of other projects in your local / personal repos, which happen all the time; heck, you will want to work with forks of your own repos for experiments; post-Git of course, b/c doing that with SVN is a pain in the ass.
- p0nce 8y ago
  I don't know why you assume I don't know git.
  - bad_user 8y ago
    When I said "you" above, I meant the royal "you", this being a public message.