Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Legit. Git for humans

git-legit.org

Post reply on HN
Print view View original

81–90 of 136 posts

Re: Legit. Git for humans

#81

Post by vidar »

phillmv wrote: post #78
ajross wrote: post #65

Earlier quoted context omitted.

I'd be curious to see a few examples. Git is guilty of using a bunch of non-standard nomenclature, and of using existing terms in non-standard ways ("checkout", I'm looking at you). But I certainly wouldn't call the interface or syntax "inconsistent" or "random". It's actually very tersely designed and very well put together. The "actual concepts" are, for the most part, first class citizens in the interface.

> But I certainly wouldn't call the interface or syntax "inconsistent" or "random". Uhm, NO WAY. git checkout works on both branches and files. I can `checkout remote-name/branch` but I have to `push remote-name branch`. Deleting a local branch is `branch -D` but deleting a remote branch is (I still can't fucking believe it) `push remote :branch`. It's surprisingly hard to unstage a file. If a rebase fails, it gives…

Yeah, deleting a remote branch by "git push remote :branch" is pretty terrible, one colon between heaven and hell.

Re: Legit. Git for humans

#82

Post by languagehacker »

I'm in full agreement with the other comments I'm seeing. These kind of additional tack-ons are somewhat pernicious to actual team-based version control, because it promotes abstracting more of the core functionality of Git outside of the user's control. This causes breakdowns in mutual understanding and the ability to communicate at the worst possible time -- when people are trying to figure out why there are weird changes to production code, or what happened to the changes they made. As a technical lead, I would actually tell a developer using this to cut it out and learn the real commands so they know what they're doing.

Re: Legit. Git for humans

#83

Post by hellerbarde »

nnythm wrote: post #48

I wrote something vaguely similar a while back, I imagined it would be useful in a hackathon context for people who had never used git before. The biggest problem was that it doesn't help people understand git, whereas all of the regular git commands fundamentally make sense if you think about the way it's implemented, and also lead you toward and understanding of git. My version was called jerk--it is a little meane…

this is brilliant :D

Re: Legit. Git for humans

#84

Post by eagsalazar »

First of all, these verbs are only marginally more intuitive than the existing git verbs. Git when it is confusing, is confusing because of the underlying interactions and concepts, not because "push" is too bewildering compared to "sync".

Second, is the global "tower of babel" noise that widespread adoption of this alternate vocabulary will cause less than the slight local reduction in noise from legit?

No. Basically, this isn't a good idea and I really really hope no one adopts this.

Re: Legit. Git for humans

#85

Post by hp »

ajross wrote: post #65
hp wrote: post #62

Earlier quoted context omitted.

I found that the syntax _was_ the hard part of git. That and the often-terrible man pages. Both docs and syntax are inconsistent, verging on random, and full of irrelevant details. It's pretty hard to figure out the actual concepts beneath all the noise and misdirection. the git vs EasyGit diff basically summarizes what I'd change about git.

I'd be curious to see a few examples. Git is guilty of using a bunch of non-standard nomenclature, and of using existing terms in non-standard ways ("checkout", I'm looking at you). But I certainly wouldn't call the interface or syntax "inconsistent" or "random". It's actually very tersely designed and very well put together. The "actual concepts" are, for the most part, first class citizens in the interface.

I agree with basically everything Elijah has to say here for example: http://people.gnome.org/~newren/eg/git-eg-differences.html

Re: Legit. Git for humans

#86

Post by ecocentrik »

eta_carinae wrote: post #54
underwater wrote: post #53

Earlier quoted context omitted.

That's silly. As developers we constantly try to make better interfaces for our users. When it comes to our own tools we supposed to put up with difficult interfaces because that's the way it is? Engineers seem to treat mastering the command line and complex tools as a badge of honour, and as a way of differentiating themselves from the noobs. If there is really an easier way then is that really a bad thing?

> That's silly. As developers we constantly try to make better interfaces for our users. When it comes to our own tools we supposed to put up with difficult interfaces because that's the way it is? We're not talking about a different interface here but a new terminology. It's a bit like saying that you think English is too hard so you'll be communicating in Spanish from now on. This is not a realistic decision in a w…

Extending your vocabulary is nothing like learning a new language. A text based interface is improved by choosing words and symbols that better represent a command with relative brevity and simplicity.

The concensus seems to be that commonly used complex actions in git have a less than intuitive structure and syntax. I think it would probably benefit from the introduction of new terminology.

Re: Legit. Git for humans

#87

Post by martininmelb »

I have always seen git as a kind of assembler language for version control. We are now starting to see some second generation languages built on git. The first batch may not be perfect, but over time we will see improvements.

I welcome these attempts to abstract git and make it more accessible. I haven't yet seen one that I think I would prefer over native git, but am looking forward to see what develops.

Re: Legit. Git for humans

#88

Post by nullflux »

eta_carinae wrote: post #56
nullflux wrote: post #50

Earlier quoted context omitted.

The same argument could be used with assembly language vs. Ruby/Python, but that doesn't stop people from using higher-level abstractions to get things done easily. They exist to streamline a process. I see much ado about nothing in these comments. Is it really that awful to alias away an odd set of tools that sometimes contradict one another? That's what every high-level language does. That's what every decent UI do…

> The same argument could be used with assembly language vs. Ruby/Python, but that doesn't stop people from using higher-level abstractions to get things done easily. That's not the right analogy. The situation here is more: you join a project that uses assembly language, which you find too hard to learn, so you decide you'll be using Ruby instead.

> you join a project that uses assembly language, which you find too hard to learn, so you decide you'll be using Ruby instead.

That's not my point. My point is that if legit gets people into using Git as their VCS, it seems silly to attack the idea because it isn't the current norm of engineering. Lessening barrier of entry to using a powerful VCS is not bad in and of itself. Not everyone jumps into assembly language. Plenty jump into higher-level languages and find themselves deeper in the rabbit hole as time progresses.

To a newbie, this legit script appears far more accessible than git's stock interface. Is it bad that GUIs exist because the command-line is often more powerful to an experienced user? Why is it so bad that this tool exists and can be used to increase overall engagement and entry into the world of Git?

Post reply on HN