Git Legit

by misiti3780 • 14 years ago

165 53 14 years ago

telemachos• 14 years ago

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• 14 years ago

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

waxjar• 14 years ago

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.

dkhenry• 14 years ago

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

haldean• 14 years ago

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• 14 years ago

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.

aaronharnly• 14 years ago

This can be done in two ways:

1. Git aliases.

You can add configuration to git so that git subcommands invoke arbitrary commands:

https://git.wiki.kernel.org/index.php/Aliases

This is what legit does, here:

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

2. Any executable in your path named 'git-foo' can be invoked by 'git foo'.

Neat, huh? It's a useful way to create your own workflow scripts without having to touch your git install.

eyko• 14 years ago

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

JesseObrien• 14 years ago

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

huhsamovar• 14 years ago

Not a fan of most of it. The people that complain about git's unintuitive interface are also not going to spend time learning how to use this either.

This doesn't improve git. It just complicates things. Stick to the interface git gives you and define your own intuitive aliases based on the ones you use the most.

The most effective way to work is to self-assess.

ovechtrick• 14 years ago

agreed. me either.

I've had legit installed for months. Only command I ever use is "switch."

I don't trust anything else.

kenneth_reitz7• 14 years ago

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

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

pavanky• 14 years ago

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• 14 years ago

Clearly it is too legit to quit!

kenneth_reitz7• 14 years ago

Open an issue! Seems like a worthy edition ;)

regularfry• 14 years ago

Quite common for projects to do that, in my experience. I lean heavily on checkinstall for this sort of thing.

malkia• 14 years ago

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

ketralnis• 14 years ago

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.

kenneth_reitz7• 14 years ago

Legit does the exact same thing that GitHub for Mac does.

"Once you're ready to share your commits, or pull in remote commits — just press the Sync Branch button. We'll perform a smarter version of pull --rebase && push that reduces merge commits but doesn't rewrite your merges."

ikawe• 14 years ago

Yup - no coincidence there

from the first paragraph on the page: "Legit is a complementary command-line interface for Git, optimized for workflow simplicity. It is heavily inspired by GitHub for Mac."

thefreeman• 14 years ago

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.

jimktrains2• 14 years ago

Understanding the working directory, stage, and commit/repo distinctions are very useful, I've found. Once you got those the rest of git becomes a bit more understandable.

kenneth_reitz7• 14 years ago

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

encoderer2• 14 years ago

What scenario are you concerned about?

I suppose if they squashed commits that weren't there's, then that's a problem of course. But just rebasing their own work between branches?

The real trouble I'd see for this mythical newbie is when they get in a situation that calls (correctly) for a force push. That would come-up if they fork an OSS repo, push some changes to their fork, then do a $ git pull --rebase from the OSS repo to bring in new changes.

When they go to push again to their fork, they will get an error that will require a force push. The force push will be fine because they are working alone, but it could cause an issue for a new git user.

But I'm a little unsure of what trouble you're afraid the maintainer would have.

dave1010uk• 14 years ago

This also assumes no one will fork or fetch from your fork of the OSS repo before you rebase.

greghinch4• 14 years ago

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_reitz7• 14 years ago

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• 14 years ago

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.

greghinch4• 14 years ago

I think I prefer typing a few extra characters to have control of each step.

StringyBob• 14 years ago

That's entirely the issue with Git for me. From the point of view of a programmer this is basic; obfuscation even. I'd love to take advantage of less painful merging/branching etc, but I work with engineers with a completely different domain of expertise - code is a means to an end. 50% of them refuse to use Git, and only accept svn grudgingly.

tjtrapp• 14 years ago

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_reitz7• 14 years ago

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.

VeejayRampay• 14 years ago

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.

borplk• 14 years ago

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

calpaterson2• 14 years ago

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• 14 years ago

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.

mjs• 14 years ago

I agree with you that they're not logical, but unfortunately I think it's too late to fix now. All the documentation, stackoverflow questions and answers, and so forth assume you're using standard git commands and terminology.

At least (in trying to match what the GitHub applications do) it's not trying to invent a completely new system. But I don't see this getting much traction unless GitHub adopts it and pushes it as their "official" command line client.

laurent123456• 14 years ago

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• 14 years ago

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?

BadDesign• 14 years ago

Seems legit!

languagehacker• 14 years ago

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• 14 years ago

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

brendano• 14 years ago

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

rsgalloway• 14 years ago

Shameless plug for my own Python git wrapper, grit:

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

Git Legit

Related Stories