Hacker News new | comments | show | ask | jobs | submit login

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

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact