If you know what these commands are doing under the covers, these commands are a true time saver. If you don't know what these commands are doing, they're basically "magic" and in the hands of inexperienced developers could be harmful to their education on Git.
Legit. Git for humans
61–70 of 136 posts
Re: Legit. Git for humans
#62Like 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.
Re: Legit. Git for humans
#63Like 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…
> "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.
For anyone who gets a panic attack before running `git reset`, this talk may help clarify how things are working under the hood: http://www.infoq.com/presentations/A-Tale-of-Three-Trees
Re: Legit. Git for humans
#64If you know what these commands are doing under the covers, these commands are a true time saver. If you don't know what these commands are doing, they're basically "magic" and in the hands of inexperienced developers could be harmful to their education on Git.
I completely agree. I hope to add a `verbose` mode that prints every git command that is being run under the covers.
It could be a good teaching tool perhaps?
Re: Legit. Git for humans
#65Like 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.
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.
Re: Legit. Git for humans
#66I 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. What if I want to publish to a second remote?
Re: Legit. Git for humans
#67Switch, synch, publish, unpublish - those all made sense, but when they started adding things like 'sprout' and 'graft' it just passed into the realm of trying to be too cute with the branching metaphor for my tastes. Personally, I'd pick git-flow over this. It seems more useful and makes, syntactically, more sense (though it can get a bit verbose at times `git flow feature start some-feature`). Starting and finishin…
Creator of Legit here.
git-flow is awesome. I use it every day.
This isn't so much of a branching model tool, but a tool that allows you to switch branches and interact with remotes very easily.
When you switch branches with Legit, any pending changes you have made are stashed automatically. When you switch back, they are unstashed. This saves me a lot of typing.
If you're following Vincent's branching model, switching from `feature/x` to `develop` happens quite a bit. So, they compliment each other well.
Re: Legit. Git for humans
#68Oh 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...
The purpose of Legit is to save time for developers that know Git well. It is not intended to be a shortcut for newcomers.
Re: Legit. Git for humans
#69This looks like it would be a nightmare for working with other developers. Other developer: "I did 'git sprout foo' and made my changes then 'git publish foo'. But now I'm not sure why the foo branch isn't on the public repo." Me: "????"
The purpose of Legit is to save time for developers that know Git well. It is not intended to be a shortcut for newcomers.
Re: Legit. Git for humans
#70I 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…
Then use `git push second-remote foo`. There's nothing stopping you from using the existing commands.
It's complementary.