
Legit. Git for humans - andybak
http://www.git-legit.org
======
jdietrich
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.

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

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

~~~
phillmv
> 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 you exactly one warning and then forever complains
about a dirty index tree. The error messages are borderline incomprehensible
for someone who doesn't understand git internals (refs/head say what?). The
reset command is far to easy to typo into oblivion.

What else. I haven't spent a lot of time thinking about it, but obtaining an
exact list of differences between branches is hard (git `log sha1..sha1`
compared with `git log sha1...sha1`).

This is just off the top of my head. Git is great, it's fast, I don't
understand people who are still on svn, but the user interface is _abysmal_.

~~~
djacobs

      It's surprisingly hard to unstage a file.
    

Is there a case when it's not a simple git reset my-file away?

~~~
ajross
Indeed no. That's exactly what git reset does: "copy entries from <commit> to
the index". I got that from the unusably bad man page. It was the first
sentence.

~~~
djacobs
My question was a rhetorical one :)

~~~
ajross
I know. But you were needlessly agreeable. I thought some salt needed to be
rubbed into the GP post.

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

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

------
hp
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
I second this, why not just use eg?

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

~~~
natch
>compliment each other well

complement.

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

------
skrebbel
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_reitz
Maybe I should update it to "Git for Humans (that already use git)"

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

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

~~~
dasil003
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
'porcelain' is completely new to me in this context. Could you explain what it
means? (and who uses it?)

~~~
cytzol
In more general terms, the 'porcelain' is the user-friendly interface
commands, and the 'plumbing' is the internal commands.

With Git, it's often said that some of the 'porcelain' commands only make
sense in the context of the 'plumbing' ones, and you should understand the
internals first before being able to use the more user-friendly interface.
It's things like this that lead people to create more friendly interfaces like
Legit here.

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

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

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

------
eaurouge
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?

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

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

~~~
RegEx
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
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

~~~
RegEx
Much more concise explanation, thanks!

------
eta_carinae
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...](http://beust.com/weblog/2010/04/06/git-for-the-nervous-developer/)

~~~
underwater
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_carinae
> 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.

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

------
orblivion
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?)

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

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

~~~
kenneth_reitz
There's nothing stopping you from using regular `git checkout` in that case :)

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

------
nnythm
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
this is brilliant :D

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

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

------
curiositydriven
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_reitz
Then use `git push second-remote foo`. There's nothing stopping you from using
the existing commands.

It's complementary.

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

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

~~~
huxley
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>

------
karamazov
Is this just syntactic sugar?

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

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

~~~
knowtheory
Incremental and clarifying progress is always beneficial.

I am on the fence as to whether this is clarifying or not. Git's problem is
not just that the command structure is... esoteric, it's that once you're off
the golden path, finding your way back onto the path is extraordinarily
difficult.

I am unclear as to what extent legit mitigates the second (thornier) problem.

~~~
untog
_Incremental and clarifying progress is always beneficial._

Only if everyone increments with it. If you have half a team using one set of
terminology and half the other then it's going to end in an unholy mess.

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

------
natch
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_reitz
Whoops, fixed :)

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

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

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

~~~
Jach
For those who don't want to click:

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

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

------
appalsap
Le Git - git for redditors.

------
jakr
I think he ment to write "Git for farmers"

------
twoism
nope

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

------
tubbo
so this is basically a bunch of aliases?

------
Kiro
I'll stick with the Git GUI.

