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