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

101–110 of 136 posts

Re: Legit. Git for humans

#101

Post by noonespecial »

hp wrote: post #62
jdietrich wrote: post #51

Like anything else in software development, the hard part to learn is the abstractions, not the syntax. People struggle with git because it's an immensely powerful tool. "git reset" has quite simple syntax, but it confuses the hell out of even experienced git users because it's very clever and potentially very dangerous. Of the altered syntax in Legit, "switch", "sync" and "publish" make sense, but "harvest", "sprout…

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.

An errant use of git force taught me that git is always logical, its just not always rational.

Re: Legit. Git for humans

#102

Post by gcb »

djacobs wrote: post #97
phillmv wrote: post #78

Earlier quoted context omitted.

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

Git checkout is actually pretty consistent and only really works on branches. When you say it works on files, you actually mean it has a shorthand that works on files: git checkout my-file ... is actually using a lot of smart defaults. Namely, you're actually running ... git checkout HEAD -- my-file If you don't specify a branch or identifier, git uses HEAD by default in most cases. (When you run git diff other-branc…

So, in the end it worked on a file. :-)

Re: Legit. Git for humans

#103

Post by 6ren »

nullflux wrote: post #88
eta_carinae wrote: post #56

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

The idea of a clean abstraction is you can predict what a particular operation will do without knowing its internal implementation.

For higher-level languages, this is generally true for the effect of a command: you can work out what a line of Ruby does without needing to think about the underlying assembly language. There are other abstractions (aka levels/layers), such as virtual memory, the OS and the implementation of the CPU itself in terms of architecture, transistors, silicon doping. (Sometimes these abstractions are said to still be "leaky" because to understand performance issues often requires knowing the underlying implementation - that's important but distinct from just knowing what it will do.)

A common criticism of git is that the abstraction is not clean - you need to know what it actually does underneath in order to predict that a command will do. It's not just a problem of an inconsistent UI (though it is that), but that the user model that the command sets out (the abstraction) does not match up with what git will actually do.

The OP's criticism is that legit (great name BTW) doesn't address this: people will use this simpler, friendlier UI, and inexplicable and weird dangerous things will happen (e.g. data loss). C++ might blow your leg off, but git can make you never have existed.

NB: I haven't looked at legit closely enough to tell if this criticism is valid (and OP offers no support - OP, please elaborate). I'm just clarifying the issue.

Re: Legit. Git for humans

#104

Post by bascule »

jdietrich wrote: post #51

Like anything else in software development, the hard part to learn is the abstractions, not the syntax. People struggle with git because it's an immensely powerful tool. "git reset" has quite simple syntax, but it confuses the hell out of even experienced git users because it's very clever and potentially very dangerous. Of the altered syntax in Legit, "switch", "sync" and "publish" make sense, but "harvest", "sprout…

The only dangerous part of git reset is git reset --hard, which will blow away uncommitted changes. It has a special flag for a reason... it's dangerous.

Beyond that, git reset won't get you anywhere that you can't get back to after consulting the reflog

Re: Legit. Git for humans

#105

Post by mainguy »

alinajaf wrote: post #34
ryanbigg wrote: post #28

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.

+1, If you just take 2 hours and read the entirety of progit.org (including the section on internals) all of these workflows on top of git start to look unnecessarily confusing.

-1, as a git user who finally submitted to learning the internals, I think this is not the right way to design software. I realize linux/et al are all geek inspired technology festivals, but to imply that a good User Interface and human accessible commands are unnecessary is... silly, the rhetoric reminds me of the elitist GNU/linux propeller heads back in 1999 who would constantly and derisively snort in disdain at "Windoze" users because they didn't know how to do a find / -name myfile.txt -print. Especially the one's who argued vehemently that the '-print' option made any sense whatsoever.

Re: Legit. Git for humans

#106

Post by djacobs »

bascule wrote: post #104
jdietrich wrote: post #51

Like anything else in software development, the hard part to learn is the abstractions, not the syntax. People struggle with git because it's an immensely powerful tool. "git reset" has quite simple syntax, but it confuses the hell out of even experienced git users because it's very clever and potentially very dangerous. Of the altered syntax in Legit, "switch", "sync" and "publish" make sense, but "harvest", "sprout…

The only dangerous part of git reset is git reset --hard, which will blow away uncommitted changes. It has a special flag for a reason... it's dangerous. Beyond that, git reset won't get you anywhere that you can't get back to after consulting the reflog

You can recover from a git reset --hard with the reflog as well, though of course if you had untracked changes you'll lose those. (I usually use git reset --hard in the process of renaming branches and not to get rid of untracked changes, so this isn't a problem for my workflow.)

Re: Legit. Git for humans

#107

Post by mainguy »

curiositydriven wrote: post #66

I like the idea here, but see one significant problem that will prevent me from using these aliases. The git publish alias doesn't take a branch name, so if you have multiple remotes for the repository it will just publish to one of them. Which one? Well, the code in legit/scm.py reads return repo.git.execute([git, 'push', repo.remotes[0].name, branch]) so it just pushes to whichever remote is first in its array. Wha…

What happens if flying green monkeys attack just before you hit "Enter"... I contend most people only use a single remote.

Re: Legit. Git for humans

#108

Post by djacobs »

gcb wrote: post #102
djacobs wrote: post #97

Earlier quoted context omitted.

Git checkout is actually pretty consistent and only really works on branches. When you say it works on files, you actually mean it has a shorthand that works on files: git checkout my-file ... is actually using a lot of smart defaults. Namely, you're actually running ... git checkout HEAD -- my-file If you don't specify a branch or identifier, git uses HEAD by default in most cases. (When you run git diff other-branc…

So, in the end it worked on a file. :-)

It worked on a branch, filtered by a file name. I think that's an important distinction. That distinction unifies the definition of `git checkout`.

Re: Legit. Git for humans

#109

Post by djacobs »

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…

  It's surprisingly hard to unstage a file.
Is there a case when it's not a simple git reset my-file away?
Post reply on HN