Hacker News new | past | comments | ask | show | jobs | submit login

but isnt git pretty much the best thing in the world since it was made by the who who remote linux? Why do u need sugar ontop of it?

Oh wait, thats right, cause guys who make operating systems dont make human software.




Wtf is "human software"? And by the way, what's wrong with adding sugar on top of a low level system? Do you program with syscalls? I bet linux must be a pretty shitty software since it requires so many libraries and abstractions for "humans" to be able to work with it.


I know I shouldn't reply to comments like this, but what are you going to do to make the (software) world better? Git's got warts but it's getting better, and there are alternatives like Mercurial if they work better for you.


The issue with git isn't that it has warts or that it's not improving - it's that it's a cli tool with bad and confusing defaults. Because people use bash for programming, the cli interface is basically an API now. So we can't change it because it would break peoples bash ci/cd scripts. That's why git is bad for humans: because it's kept backwards compatible in order to be good for computers.

I keep arguing that the unix model of using the same api for human consumption as for scripting is broken. One needs to be concise and doesn't need to be backwards compatible (interactive use), the other needs to be descriptive and backwards compatible (sctipting use). Git wasn't designed in the 70's so could easily have avoided this.


> bad and confusing defaults

Compared to what? It's leagues better than what it replaced (SVN & CVS) and it's pretty comparable to Hg tbh.

So what's your preference here?


> Compared to what?

Compared to how it would work today if it wasn't constrained by backwards compatibility, and it was designed for ergonomics rather than power. Every time a best practice changes, or a new default is considered best practice, or you notice a typical usage pattern means a particular command is much more common - then the interface should reflect it. There have been multiple wrappers such as this one - but there could be room for a big official cli tool that is not backwards compatible (want to script? - call git directly).

> It's leagues better than what it replaced (SVN & CVS) a

Git as a tool is better than svn and cvs - but I don't agree its interface is. This is of course an unfair comparison since svn, cvs etc is so much simpler (It's after all a LOT easier to make a good UI for a ToDo app than for facebook). The best comparison for an UI of a "modern" vcs is git vs mercurial.


I find mercurial (I referred to that above as Hg) to be more or less the same as Git. Their CLI commands are very very similar.

What specifically are you complaining about here?


I think hg is more consistent, more polished, and sometimes involves a bit fewer steps to accomplish the same tasks.

One of the best (and funniest) criticisms of the git command line is the famous git koans. http://stevelosh.com/blog/2013/04/git-koans/

git branch -d

git remote rm

Is a prime example of how, if you designed it from scratch, you wouldn't leave inconsistent. "List things", "delete things" etc are activities that should work the same for all kinds of objects. the Git cli isn't designed with that thought. It's organically grown and every change is more or less irreversible because the human interface UI is used in programming (What I like to think of as the biggest flaw of Unix)


A comment that states the obvious? Im merely pointing out the power of the OSS hype-machine.

Like it would make sense to me if everyone who used git also used VIM, but they dont. Its a testiment to the power of the flock, that a product which gets its core functionaly so wrong, be used by so many ppl.

as for the topic at hand, if my company had invested so heavily into such a product, i would be doing everything in power to make it work. let alone if my companies core business was all in on it like github, it would be a no brainer and i cant beelive its taken so long to get the top of the backlog. looking forward to the nxt installment of hub which introduces propriority commands and see if they get treated like MS does :)


It's all about the ROI for GitHub - git works well enough for them.

If a problem in Git was causing a problem for GitHub I'm sure they'd work to fix it. Although I don't see any @github addresses in git's git.


There certainly are github employees who contribute a lot to git, but not with their github e-mail address, but with their personal address.



You realise MS uses git and github internally right?

But hey if you're a happy TFS customer then good for you...




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: