Hacker News Reader

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.

>> ...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

What are some arguments to be made against git?

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.

To save you some time and unhappiness:

Yes, git’s UX is absolutely terrible. It is an abomination. It is the worst command line tool I’ve extensively used in that regard. For a long time I stubbornly used mercurial, which is vastly superior.

But, it has become a de facto standard. This is a tragedy. But it is a fact.

So it is best just to spend time learning it, find a subset of commands and make a cheat sheet you can refer to, and accept that the world is imperfect. Hopefully at some point in the future git will die and we will transition to the next big thing, and they will get it right that time.

There are many such things in the world of tech, and in most cases it is best to say “yes, it’s awful, but no, I can’t change it, and rather than expending energy on hating it (which is totally justifiable) I will expend the energy on minimising its damaging impact to my productivity and focus on accelerating my work elsewhere.”

I say this because I have spent so many hours ranting about git and every time it gets in my way (git submodules anyone?) I used to get so stressed by its design that it would hurt my productivity.

Be the Zen Dev: acknowledge it, isolate it, keep it at arms length.

Tips: Make a cheat sheet, use a minimal feature set, don’t try to do anything clever with it, and always have a way out (eg backups! Take copies of your directory before dealing with lesser know commands! Try things out on dummy repo’s before breaking your own, etc.).

> But, it has become a de facto standard. This is a tragedy. But it is a fact.

I feel this sentiment so often in this field. It’s really distressing.

Are you familiar with "worse is better"? Sometimes what makes a technology a pain to use is also what makes it competitive.

> This is a tragedy.

I don't think it's a tragedy. UX can be fixed (even if difficult because of backwards compatibility and social concerns). Changing the underlying technology is much harder.

git has become a de facto standard because it gets everything else right.

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.

Sorry but if the error gives you the right command to run first time then it should just run it first time by default. Sane defaults for new users is good UX. Not an error telling you exactly what command to run instead. It already knows what you intended, for Christ sakes, because it's telling you what you should copy and paste instead!

But it doesn't know what you intended. It's guessing. The consequences of guessing incorrectly could be very, very bad, as you are pushing your code to a remote host.

Again, the whole point of git is that it is decentralized; there is no requirement that you have one single central server that you are pushing to; there could easily be multiple places that you might want to push something to.

Using something as default that makes sense for a centralized VCS when git is not centralized is, imho, worse than bad UX, as it teaches incorrect assumptions.

Again, this is table-stakes knowledge for using decentralized version control.

It's not necessarily always the correct command to run, it's just suggesting what you probably want to do.

Which should be the default, based on popular use. You can always use the command it suggests to do something different.

Well considering how many people who now know git and understand it, it doesn't make sense to do that necessarily. Rather they should make it a configurable option which do now see push.default (https://git-scm.com/docs/git-config)

Right, which means changing it will harm the UX due to ingrained pattern. That's not what I'm arguing for.

I'm arguing against the idea that showing an error message with the exact command to use is good UX - see the original comment. It is not.

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/ - 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.

Have you tried the official GitHub client? I've worked at a few places where non developers started to use it because the ability to collaborate through pull requests has so much benefit outside of development. I'm a huge fan of IntelliJ and use the inbuilt git client most of the time, it abstracts most of the complexity. Sourcetree is another good product.

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

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.

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.

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".)

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.

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.

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...

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.

    diff -ruN dir1 dir2

Use your favorite merge tool for changed files (like in git).

(Of course, proper VCS wins any day.)

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

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.

I don't know why you assume I don't know git.

When I said "you" above, I meant the royal "you", this being a public message.

I agree with you 95%. If you're running something basic with less than 5 people this is reasonable with one minor caveat:

  I'd still use git.

Hell even on my own I frequently use git for single file shell script. Commit a working copy. Tweak it to add a feature. Decide it's unmaintainable. Revert to before I fucked it up.

Also, theres a decent half-step between ssh and Ansible: mssh. You can run ssh across a set of hosts quite trivially. It working on the order of a few dozen machines just fine.

my personal take on mssh is: for host in host1 host2 host3 ; do...

True, that works too. I'm good with bash but I find many aren't. I actually work with bigger setups (think thousand machines) that have range set up which is a big value add with mssh but not in the kinds of small setups we're discussing.

> with no care in the world about version control (rsync does most of what I need: backups)

I get the simplicity...but using git/hg/svn is just so easy. And you can easily rewind, diff, view changelogs for a file, etc.

I am not convinced that git is easy... I believe it's very powerful if you put the time into learning it, but anything with 50,000 separate guides on the internet must be somewhat unintuitive, right?

Definitely are way more intricacies to the cli than I'll ever learn, but 99.7% (estimated) of my git usage is running the same 4-5 commands all day, which I have aliased to convenient acronyms. Don't even have to think about it.

The other stuff is there if you need it though.

Git does 50,000 things, but to get started on your local machine you only need 4 commands.

When you're setting up for the first time:

  git init

When you've made a change you want to keep:

  vim foo.txt
  git add foo.txt
  git commit -m "Add foo.txt to project to enhance synergy"

When you did something wrong and want to go back to when you last ran git commit:

  git checkout foo.txt

Everything else builds on top of that workflow.

Use a GUI like SourceTree from Atlassian, makes dealing with "git" so much easier.

I’ve still been unable to find something that has the right balance of intuitiveness as well as surfacing advanced features and workflows besides SourceTree. The only downside is that SourceTree is slow and buggy at times.

Not to mention it lacks certain useful features like being able to change the head but the convenience factor won me over anyhow in the end.

Eh I couldn't rebase to save my life but basic git is fairly easy to grok and useful.

It’s exactly like merging but you have to resolve any conflicts commit-by-commit instead of all at once in a merge commit. Useful for if you’ve been working on a feature and want to pull in changes your colleagues have made on the develop or master branch without muddying up your history with merge commits. Having clean history makes diffing easier for code reviews. I’ll admit even after years of rebasing, I still screw it up from time to time.

There are 50,000+ ways to learn anything, and most won't work for most people. Sometimes I have to read 20 different takes on something before it finally clicks.

The fact that there are so many people trying to explain it in their own way is a good sign.

That seems more of a function of how popular it is. But I can’t even remember learning git anymore; maybe it is hard to learn.

Not necessarily, you can also use it just like CVS in the old days, with 2-4 commands, should be enough for your needs.

I agree that managing complex workflows, or really any situation involving a lot of contributors/branches/activity may send you running to your nearest search engine with regularity.

That being said, for GP's use, they can work solely from master, requiring only a few commands with little to no chance of difficulty.

You can write off something as being hard if lots of people want to help you learn it and share their tips and advice, but then you're just ruling out learning anything worthwhile, really.

How many Python guides are on the internet?

git takes typing more commands and bothering about the repo.

rsync is run by cron.

If you want to do something dirty, you could schedule commits with cron.

Im confused why Python, Postgres, Markdown is 1996 tech? Im really confused by your entire post, actually.

I meant all this is super old school and super dirty, except markdown that is somehow recent (2004)

Yet markdown is not essentially different from running sed to render something into html, which I would have totally done if I hadn't also needed some other features like basic math that would have been too tedious in sed

I mean yea, but it is like saying, "I respond to server requests with HTML, it's soo 1994". I do like the sed idea, btw :)

lol yes I would not have used anything else if I could have gotten away with sed!

Speaking of HTML, I do my HTML sites all static, with no external scripts or resources! It is so 1994.. or so 2018??

Pretty much the same except that I use `git push` to deploy instead of `scp`. If I ever need to move beyond a single server that'll be an issue but for now it's fine.

For my hobby stuff I am similar. Perl and either SQLite or Text files. Sometimes Postgres, but I rarely find it is needed, even for fairly popular anonymous boards.

I use vi. I do use git locally, but I don't trust it, so I also use rsnapshot, probably similar to your rsync. You might want to try rsnapshot some time if you have not. It uses less disk space by hard linking dupes using a perl script.

Curious as to why you'd prefer Perl? Is it because of a technical reason or just because of familiarity? Thx