Live data from Hacker News

Legit. Git for humans

git-legit.org

41–50 of 136 posts

Re: Legit. Git for humans

#41

I strongly disagree with the purpose of this. It still has precisely the same problem that regular git has: you need to understand the language behind it. Just learn regular Git rather than re-inventing the language.

I don't disagree with the purpose, the git CLI interface is pretty inaccessible to non-developers—more than it needs to be.

But you're totally right about the implementation. This just adds more commands under the git namespace, muddying the waters as much as providing a simple interface.

If the goal is to make git for mere mortals then what is necessary is to create new porcelain from the ground up and call it something other than git. That's a lot more work obviously, but git internals were defined to enable just that! Then in the fine print you could say "oh btw there's git under there for anyone that needs it". That's my idea, but maybe it would be better to just use Mercurial?

Re: Legit. Git for humans

#42
post #30

EasyGit, single script, very well thought out, longstanding tested project, doesn't "conflict with" or conceal the underlying git just fixes up the UI. http://people.gnome.org/~newren/eg/ https://github.com/blog/333-easy-git

I second this, why not just use eg?

Re: Legit. Git for humans

#43

It seems that git is the new regex. People are actively building things around instead of learning the rules. I suppose that came from writing being easier than reading.

I know regular expressions way better than most people I come across and I still never feel to good about my command of the more 'esoteric' features.

Having a version control system ( something that more people will use more often every day than regexes ) compared to them, is not a heartening thought.

Re: Legit. Git for humans

#44
I welcome all attempts to create a better UI for git. Perhaps legit isn't it. Don't care. Eventually we will get this right.

I prefer git's internal branching model and few other features to mercurial but I really prefer the UI to git.

Keep it up people, eventually we will have a better ui.

All that said, I'd encourage people who are doing it, to not add the 'git' namespace. Create your own and just use the internals. Systems that add new 'git *' commands are just confusing an already confused situation.

Re: Legit. Git for humans

#45

Earlier quoted context omitted.

I disagree. A lingua franca is important. If these are indeed common operations, then it's important that everyone talking about, say, `git sprout` means exactly the same thing.

"A lingua franca is important" Exactly! And that lingua franca already exists. This is only useful if you would like a new syntax for personal use and you're too lazy to or don't want to use 'git alias'.

That argument says that we should never codify abstractions built on top of pre-existing lower-level components. Not sure I can agree with that.

Re: Legit. Git for humans

#46

Earlier quoted context omitted.

Erm... push behaviour can be changed using config and will be changed in the next release to only push the current branch. My git pull pulls the current branch...

> Erm... push behaviour can be changed using config Right, and isn't that what legit is providing here? Sane defaults. I'm in favor.

The point is, the best way to improve suboptimal behavior in an open source project is to engage with the project and advocate changing the behavior. If there is truly a defect, or a behavior that so needlessly violates the principle of least surprise, then fix it at the project level.

Re: Legit. Git for humans

#47
Oh dear. Please, no. Just, no.

git's user interface is terrible and very counter-intuitive, but if you want to work in a team or, more to the point, be productive and leverage what git has to offer, do take the time to learn its native user interface.

Related article:

http://beust.com/weblog/2010/04/06/git-for-the-nervous-devel...

Re: Legit. Git for humans

#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 meaner than git, and supports operations like "undo".

https://github.com/mnn2104/jerk

Re: Legit. Git for humans

#50

I strongly disagree with the purpose of this. It still has precisely the same problem that regular git has: you need to understand the language behind it. Just learn regular Git rather than re-inventing the language.

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 does across any paradigm.

Abstractions make things easier for the human in many cases. If Legit increases the productivity of a team of developers and gets newbies using the Git VCS, more power to them and its use. They can learn the internals later.

Post reply on HN