Legit. Git for humans

http://www.git-legit.org

by andybak • 14 years ago

361 131 14 years ago

git-legit.org

karamazov2• 14 years ago

Is this just syntactic sugar?

arthurbrown2• 14 years ago

Looks like a set of aliases. Relevant source is here

https://github.com/kennethreitz/legit/blob/develop/legit/cli...

batista3• 14 years ago

I take offense to the "just" and the "sugar".

You making sound like something bad for your health.

An alternative syntax can make:

1) usage simpler 2) multiple step processes turn to one step 3) commands easier to remember 4) less error prone

(or the opposite, depending on the specifics of the new syntax).

So, no, this is not "just syntactic sugar" this is "new syntax", that is: an alternative command line user interface.

karamazov2• 14 years ago

The phrasing is intentional - a new syntax needs to be substantially better (as opposed to slightly better) than the old one to justify adding an additional standard.

eaurouge3• 14 years ago

Looks like it's just aliases. You might as well just use 'git alias'. There's no need for a new universal set of commands - it defeats the idea of configuring your very own Git.

alexchamberlain3• 14 years ago

I'd have to agree. Git is very Unix - simple commands do one simple thing - it doesn't need complicating by opaque commands that do lots of things at once.

MatthewPhillips3• 14 years ago

But Git commands map to what is going on in the code, which isn't necessary. I think an effort to make a true CLI for git should be encouraged. For example:

  git push

Pushes everything, in every branch.

  git pull

Whoops, won't let me do that without providing a branch.

reinhardt• 14 years ago

I hope so. Lack of syntax sugar is "just" what forces me to stick with mercurial + hg-git.

skrebbel• 14 years ago

They say it's for humans, but then explain the commands in terms of "normal git".

This'd made a lot more sense for me if they explain for what particular workflow it's intended and how to use it as such. With examples and all.

kenneth_reitz9• 14 years ago

Maybe I should update it to "Git for Humans (that already use git)"

nullflux3• 14 years ago

Why not make it "Git for humans (that don't use git yet)"?

obtu• 14 years ago

I just dislike the “for human beings” meme/fad.

1. It's casually dismissive of us cyborgs, who are too often marginalised already;

2. It's a subjective claim;

3. It claims you have taste that your competitors lack;

4. I've seen enough examples where my taste finds something inferior or seriously wrong with the design (not saying this is the case here) that I don't take these claims seriously.

orblivion• 14 years ago

I hope the developer thought very carefully about how to handle doing operations starting from unusual states.

"# Switches to branch. Stashes and restores unstaged changes."

I guess I can't think of anything in particular, but I feel like something unexpected could go wrong here.

(I didn't know you could pop a the last stash that was made on a given branch?)

arthurbrown2• 14 years ago

It seems like the use case he's optimizing for here is if you're accidentally on the wrong branch, and need to move your working changes over to the correct branch.

Personally, I almost always use stash if I'm not quite ready to commit, but need to quickly fix a bug that takes precedence over whatever I'm currently working on. I stash what I'm doing, fix it, and them come back. Some of these operations seem at odds with my workflow.

Jach3• 14 years ago

I've used that workflow too. What disturbs me about the `git switch` proposed here is the unstashing. I think the intended optimization is more general: when you're trying to switch to another branch for any reason but git doesn't let you because of unsaved changes. But your use case of being on the wrong branch seems like the actual optimization for a fairly (at least for me) uncommon workflow. More frequently I, like you, stash and switch, then possibly do something (or not) like immediate bug-fixing, then switch back and unstash only then.

ryoshu• 14 years ago

This 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: "????"

LockeWatts• 14 years ago

That's a terminology problem, not a design problem.

alinajaf3• 14 years ago

While I'm perfectly happy with the stock git porcelein commands (and generally don't like any attempts at simplifying them, including gui tools) other developers having a different workflow isn't the reason.

I think having shortcuts and wrappers like the above is fine if you have a good understanding of the underlying data structure you're manipulating. You're only going to run into problems if you treat these commands as magic and just hope they work.

eaurouge3• 14 years ago

I understand that Git is a fairly complex utility. But you can accomplish a lot just memorizing about 5 Git commands and what they do. Besides, if you decide to use an abstraction such as this one without understanding the plumbing, what do you do when 'git sync' fails due to conflicts?

raganwald• 14 years ago

The same thing I do when my hardware misbehaves and I don't understand how it works and why it failed.

:-)

Just kidding. Argument by Reuction Ad Absudum is fun, but in this case, you make a good point. There is a difference between a utility designed to make someting you understand easy and a utility designed to put an easy-to-understand facade in front of something you don't understand.

kenneth_reitz9• 14 years ago

The purpose of Legit is to save time for developers that know Git well. It is not intended to be a shortcut for newcomers.

When a merge fails, it gets you out of the merge conflict state and prints a nice message about what to do next.

MatthewPhillips3• 14 years ago

For those, like me, that had never heard of pip:

http://pypi.python.org/pypi/pip

Jach3• 14 years ago

For those who don't want to click:

pip: because creating a replacement for easy_install was simpler than creating easy_uninstall.

Jach3• 14 years ago

I think the only two commands from this I like are `git sprout newbranch` and `git unpublish branch`. But only because I think `git checkout -b newbranch` and `git push origin :branch` are stupid syntaxes for doing what they do.

RegEx2• 14 years ago

I agree regarding `git push origin :branch`.

From the git man pages [0]

> git push origin master:refs/heads/experimental Create the branch experimental in the origin repository by copying the current master branch. This form is only needed to create a new branch or tag in the remote repository when the local name and the remote name are different; otherwise, the ref name on its own will work.

So, a direct substitution of `git push origin :experimental` says

    Create the branch :experimental in the origin repository by copying no branch

I definitely think that could use another layer of abstraction.

[0] http://linux.die.net/man/1/git-push

hammerdr• 14 years ago

git push origin refa:refb

  PUT a branch refb with the commit-ish refa

git push origin abc123:refb

  PUT a branch refb with the commit-ish abc123

git push origin :refa

  PUT a branch refa with the commit-ish null

kellishaver• 14 years ago

Switch, 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 finishing features, hotfixes, releases, etc. handles all of the necessary branching, merging, and checkouts for you while adding structure and basically documenting the lifecycle of the code in your commit logs.

Maybe it's not as 'human friendly' as sprouting a branch, but starting and then finishing a feature sounds pretty straightforward.

https://github.com/nvie/gitflow

kenneth_reitz9• 14 years ago

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.

natch2• 14 years ago

>compliment each other well

complement.

ryanbigg• 14 years ago

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.

alinajaf3• 14 years ago

+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.

mainguy2• 14 years ago

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

dasil003• 14 years ago

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?

andybak• 14 years ago

'porcelain' is completely new to me in this context. Could you explain what it means? (and who uses it?)

nullflux3• 14 years ago

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.

eta_carinae3• 14 years ago

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

hp3• 14 years ago

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

aioprisan• 14 years ago

I second this, why not just use eg?

manojlds• 14 years ago

Looking at the commands, eg could have been substituted with hg

Kiro• 14 years ago

I'll stick with the Git GUI.

ecaradec• 14 years ago

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.

batista3• 14 years ago

Well, regex has a horrible syntax too.

The mathematical principles underneath are good, but the standard regex syntax is arcane and values brevity over readability, modifiability, etc.

cytzol2• 14 years ago

I don't want to venture too far off-topic, but when the Perl 6 folks re-designed regexes, they found out that they weren't really designed for anything; the syntax just grew, and common features were sometimes longer than rare ones: http://www.perl6.org/archive/doc/design/apo/A05.html (section "Poor Huffman Coding").

I haven't studied enough of the Git plumbing to know what's going on underneath, but I suspect that the same thing is going on, where features are added without regard to other ones already present (feel free to correct me on this)

spooneybarger2• 14 years ago

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.

pjscott• 14 years ago

Underneath, git is actually based on a really simple tree-of-objects data structure. All those esoteric features are built on an elegant base; understand that base, and you can understand anything git does (though it may not be obvious at first).

samuel1604• 14 years ago

More stuff to remember, I'd rather remember the original commands to be honest.

zephjc• 14 years ago

It's probably better to just write one's own wrapper for git that best fits you/your company's workflow, especially if it's for your company, since you can better justify the time spent writing the wrapper code. As a point of reference, the company I work at (five devs total) is moving off cvs(!!!) to git, but writing a wrapper tool to git to create branches and set them up in the manner we need for our product.

kenneth_reitz9• 14 years ago

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.

spooneybarger2• 14 years ago

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.

eta_carinae3• 14 years ago

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.

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

underwater• 14 years ago

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?

eta_carinae3• 14 years ago

> 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 world where you need to work with a lot of people who all communicate in English.

kenneth_reitz9• 14 years ago

The purpose of Legit is to save time for developers that know Git well. It is not intended to be a shortcut for newcomers.

nnythm• 14 years ago

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

hellerbarde• 14 years ago

this is brilliant :D

tubbo• 14 years ago

so this is basically a bunch of aliases?

jdietrich• 14 years ago

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" and "graft" are no more intuitively obvious than the git equivalents.

hp3• 14 years ago

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.

ajross4• 14 years ago

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.

noonespecial• 14 years ago

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

tkaemming• 14 years ago

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

bascule• 14 years ago

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

djacobs6• 14 years ago

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.)

desireco42• 14 years ago

I personally like git-flow, but this is just a symptom of git inconsistencies, like git branch and git checkout both work with branches. I think it would be very useful to have higher level git that would be adopted as standard interface.

Fluxx• 14 years ago

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.

kenneth_reitz9• 14 years ago

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?

abhikshah• 14 years ago

Actually, a 'debug' or 'dry-run' mode that simply prints out the git commands without running them would be useful for all kinds of users. Newbies can learn from it and pros can make sure that the commands are going to do what they expect it to. With git, I know what each command does but my concern with legit (and similar) is that the higher level commands might not do exactly what I think based on their name/description.

curiositydriven• 14 years ago

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. What if I want to publish to a second remote?

kenneth_reitz9• 14 years ago

Then use `git push second-remote foo`. There's nothing stopping you from using the existing commands.

It's complementary.

mainguy2• 14 years ago

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

icco• 14 years ago

Seems like a cool idea, but would be way (I've never even heard of the pip command before) better if it could be installed in one command. See http://betterthangrep.com/, https://github.com/defunkt/gist or http://beginrescueend.com/.

ashconnor• 14 years ago

pip is used to install Python packages.

huxley• 14 years ago

Pip is a replacement for easy_install

http://pypi.python.org/pypi/pip

Pip compared to easy_install:

http://www.pip-installer.org/en/latest/other-tools.html

languagehacker• 14 years ago

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.

eagsalazar• 14 years ago

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.

martininmelb• 14 years ago

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.

natch2• 14 years ago

From the site:

>Legit is a complimentary command-line interface for Git

I do realize it's free, but I think you mean complementary.

kenneth_reitz9• 14 years ago

Whoops, fixed :)

philwelch• 14 years ago

The problem with "porcelain" like this is that it's invariably opinionated, and sometimes I'll want to do things that the simple, opinionated workflow doesn't allow for. And you still need to learn how Git works, which isn't really that difficult for someone who already understands the concept of a linked list, i.e. any competent programmer.

twoism• 14 years ago

nope

appalsap• 14 years ago

Le Git - git for redditors.

pirateking• 14 years ago

I really like this idea. I consult Stack Overflow or the git man pages frequently enough to make it annoying, but infrequently enough to have the appropriate magic incantations become instinct.

However, if I am going to distance myself from the bare metal of git, why not go all the way and use something like GitHub for Mac? That seems like a true "Git for humans". I love working from the command line as much as possible though, so I will watch this closely to see if it becomes widely adopted.

jakr• 14 years ago

I think he ment to write "Git for farmers"

Legit. Git for humans

Related Stories