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.

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

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.

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.

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

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?

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.

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.

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

Yes, then you're effectively running your own OSS project as well. If you want to be in that business, new rules apply. But just working privately on a forked repo? Legit will be fine.

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

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

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

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.

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.

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.

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

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.

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

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

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

agreed. me either.

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

I don't trust anything else.

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.

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.

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?

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

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.

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.

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

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.

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

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.

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.

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

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

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.

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

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.

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.

If someone's running an executable you give them without knowing what it actually is, their security is already lost. So yeah, that's a problem, but nothing specific to Legit or git.

How is that any different than replacing any other binary in your filesystem?

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.

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.

Clearly it is too legit to quit!

Open an issue! Seems like a worthy edition ;)

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

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

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.

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.

Shameless plug for my own Python git wrapper, grit:

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

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

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

Seems legit!