
Git Legit - misiti3780
http://www.git-legit.org/?
======
telemachos
299 days ago - 132 comments: <http://news.ycombinator.com/item?id=3752447>

168 days ago - 26 comments: <http://news.ycombinator.com/item?id=4332971>

Not complaining at all about the repost, but I remembered previous discussions
and people may find comments of interest there.

~~~
sophacles
Offtopic - I like this style of repost notice, thanks.

(Since this forum closes comments after N days on an article, reposts are the
only way to continue discussion, however, context about previous discussions
is always nice!)

------
ketralnis
This may be useful for a single beginner working only on their own projects,
but I don't really want to be dealing with users submitting pull requests that
they've made using a tool that tries to be clever about rebasing and merging.
Unless it's right 100% of the time there's going to be a lot of difficult
merge work to be done by the acceptor, that the submitter is unlikely to be
able to understand how to do if they've been relying on a crutch. They may
think they are using git, and see their code appear on github, but for the
purpose of patch reviewers/mergers they are using a totally different version
control system that can't properly talk to normal git users.

~~~
thefreeman
I have to agree here. The functionality it replaces really is not complicated.
All you do by abstracting it is ensure that when things go wrong the user has
absolutely no idea how to fix it. People should just take the minimal time
required to learn git.

~~~
kenneth_reitz
This project is not intended for beginners. It is intended to save typing for
a particular git workflow.

~~~
tmoertel
Some friendly, candid feedback: If Legit is not intended for beginners, why
not say so on the project page?

"Git Workflow for Humans" "optimized for workflow simplicity" "branch
workflows are dead simple" "Nice and simple – the way it should be"

As Legit is now described at www.git-legit.org, what would suggest to
beginners that it's anything but the answer to their prayers?

------
borplk
Oh fantastic!

More stupid terminology. Just what git needs.

switch, checkout, pull, push, commit, stash, branch, tag, fetch, merge, log,
reflog, tree, clone, rebase, squash and cherry pick

isn't enough! let's add

publish, unpublish, harvest, sprout and graft

~~~
calpaterson
The problem with the existing terminology is that it isn't logical. git reset
for example, does three separate things. Rebase is described as "Forward-port
local commits to the updated upstream head" - something which makes no sense
if you don't know about git's internals.

~~~
nhaehnle
The thing about git is that the key concepts of its internals are sufficiently
clean and sufficiently fundamental to distributed version control that they
are both easy to understand and very useful to understand.

So what you say isn't really true. I would improve it to say that the existing
terminology doesn't _appear_ logical until you have learned about those
basics. This is not the fault of git: any system becomes incomprehensible if
you approach it with concepts in your head that are incompatible with that
system.

A complete beginner may not want to start out by learning those internals, and
that's okay. But at some point, it definitely becomes a worthy investment to
take the mere hour or two that it takes to read through the relevant parts of
the documentation.

~~~
calpaterson
It's nothing to do with being decentralised or not. There are decentralised
version control systems with better command line interfaces. Some of them even
predate git. Mercurial has a better interface. So does darcs.

~~~
greghinch
Strongly disagree that Mercurial has a better interface. I've worked on
projects in cvs, svn, git, and hg, and I have to say I found hg's interface
nearly as confounding as cvs.

Not wanting to argue which perspective is _right_ , just that you can't make a
broad sweeping statement that Mercurial has a better interface

------
JesseObrien
Really not a fan of "sprout", "harvest" or "graft". They're not descriptive of
what's happening just by their name.

~~~
kenneth_reitz
Open a GitHub issue. I wouldn't be against removing.

In practice, the only ones I use are sync, publish, and unpublish.

------
laurent123456
This is a nice little tool, however the problem I see with it is that if you
learn how to use it, you'll be completely lost as soon as you move to a
different computer. You'll basically always have to install it everywhere, but
sometime that's not possible. It's much better to learn how to properly use
git from the start. Also it's just not that hard to use, so I'm not sure it's
useful to add another layer of abstraction.

~~~
nmcfarl
I've heard the argument used against any editor that's not vi (and once
against any editor that wasn't notepad), and against the use of source control
it's self - "cvs won't be on every machine, it's better to just learn to use
tarballs and patch files." (Not joking)

Most people as a normal part of their job can indeed install software on their
development machines. And those that can't won't even be looking at new
software projects - what would be the point?

------
greghinch
So basically this is a way to change git's verbs? I haven't ever found them
_that_ obtrusive. No worse than learning some language syntax

~~~
kenneth_reitz
This project is all about workflow. The workflow provided by 'git sync'
normally takes five commands:

$ git stash $ git fetch $ git merge origin/$current-branch $ git push origin
$current-branch $ git unstash

It's actually slightly fancier than that, the push actually reduces merge
commits but doesn't rewrite your merges. Same as GitHub for Mac.

~~~
anonymous
Actually it's just $ git pull --rebase

If you do have local changes, then you would need to git stash/stash --pop
before/after that command. I use rebase to keep down on unneeded merges for
the common case of having exactly one upstream and not merging several
branches together.

~~~
kenneth_reitz
If you simplify like so, it is still push and pull. One less thing to type.

~~~
greghinch
I'll never understand this subset of the development community who is obsessed
with saving a few keystrokes. It almost invariably comes at the cost of
flexibility, and creates a set of developers who only know the abstraction.

I'm looking at you, jQuery.

------
languagehacker
I'll also chime in to complain that it's just a cutesy oversimplification of
Git. Git's a really powerful tool, and you should learn it. If you don't feel
like incurring the cost of mastering pure Git, and want to use some
abstraction layer on top of it to get your work done, then it's on you when
those abstractions break or the workflows become far too restrictive. You can
plan workflows as much as you want, and they'll work about 85% of the time,
the there's 10% of the time you'll need to do crazy shit with Git, and another
5% of the time you may have to do some actual disaster recovery with the
reflog. Unfortunately, the percent of time it takes to really master these
skills are inverted. But if you're using Git's core functionality, it's a lot
better practice in conceptualizing the harder functionalities.

~~~
porker
What kind of unreal world are you living in? Do you deal with normal
programmers, you know, the kind who don't read HN and are more interested in
their paycheck? The kind that are normal employees and not geeky?

For them, Git is a mystery that just doesn't seem to be able to be mastered,
no matter how much reading, training and practice you get them to do. I spend
my life consulting with such firms and I've introduced Git to each, but only
at one have they managed to keep using it without screwups.

Anything that would simplify Git for the ordinary mortal human being, who
wants to use it for team collaboration and to have a change history and a
branching/merging model that works (unlike SVN), would be greatly welcomed. As
it stands it's great for uber-coders/HN readers (those it was designed for),
but for normal people...

------
dkhenry
I am less interested in legit and more interested in how they extended git to
make it so all their new commands worked.

~~~
haldean
You don't need to extend git; the git command "git $FOO" just runs the command
git-$FOO; git-commit, git-add, etc. are the binaries that do a lot of the
work. In this case, I imagine they install binaries like git-sync, git-graft,
etc. when you run "legit install".

~~~
habosa
Is this a vulnerability in some way? Like could I replace someone's git-add
binary to expose private source code? It scares me that someone can change my
git behavior so easily.

~~~
skymt
If someone can replace your `git-add` binary or put their own in a directory
earlier in your $PATH, they can do the same with `git`, `ls` or any other
program.

------
VeejayRampay
Amongst the usual HN negativity, I'll say that this is nice. Any project
aiming at lowering the bar of entry for proper DVCS is more than welcome. And
all the commands make sense once you're in the "tree/branches/organism" frame
of mind.

------
pavanky
There is legit install, but no legit uninstall ? It is as simple as editing
the aliases to remove what is unnecessary. But would have expected it to be
there.

~~~
rman666
Clearly it is too legit to quit!

------
tjtrapp
I feel one would benefit from learning the few simple commands of git versus
this abstraction.

once this abstraction leaks (and it will), one will be forced to the git docs
anyways.

my $0.02

~~~
kenneth_reitz
This project is not intended to be an additional porcelain layer on top of
Git, but a simple workflow tool.

> Legit is a complementary command-line interface for Git, optimized for
> workflow simplicity. It is heavily inspired by GitHub for Mac.

------
waxjar
I get that some of the commands are meant to have some connection with "the
trees concept", but I doubt these terms are easier to remember than standard
git comments.

Some are much clearer though, especially switch, sync and publish.

------
rsgalloway
Shameless plug for my own Python git wrapper, grit:

<http://rsgalloway.github.com/grit/>

------
malkia
Wondering whether straight install for cygwin would work... Well I guess I
have to try.

------
brendano
legit's "git branches" reminds me of git-wtf, which has saved me many times:
<http://git-wt-commit.rubyforge.org/>

------
BadDesign
Seems legit!

