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