51–60 of 100 posts
Earlier quoted context omitted.
You say that, but the next version of Visual Studio's gonna have git built in. Seriously. Gonna be a lot of new (and probably confused) users out there.
But VS won't require using command line
Git has a lot of UI problems. This is not really surprising. It's gotten a lot better, but I do think that no matter how proud Torvalds is of the fact that he never looked at another version control system for inspiration, a lot of pain could have been avoided if he had (even while still going in the different directions he did). Not all of us had the 'luxury' of never working with version control before. But don't g…
>no matter how proud Torvalds is of the fact that he >never looked at another version control system for >inspiration What gave you that impression? Git was strongly influenced by BitKeeper and to a much lesser extent by Monotone. And, arguably, 'anti-inspired' by several other VCS's Linus would have surely been at least passingly familiar with.
I think most of the outside influence came from people who weren't Torvalds, but the command set is just so weirdly different from every other VCS (even where functionality maps nearly 1:1) that it seems likely that it was designed without much consideration for existing use patterns of other VCS'.
Earlier quoted context omitted.
Git doesn't have much of a user interface because it's target is developers who want to use the command line. Git is confusing until it's not, and then it's awesome. It's kinda like you're using wget to surf the web, and complaining that it doesn't have a GUI. http://git-scm.com/downloads/guis
GUI != UI parent comment is arguing that the command-line interface is nontrivial, which is a fair criticism. Contrast with 'cp' or 'mv'
I'm not trying to argue that git is divinely inspired or whatever— this is confusing behavior. It tells me I can lose history, but this is a revision control system, surely they don't mean I can actually lose history? Sorry, but why did you think that they said that except to tell you that you could actually lose history? You ignored the rest of the error message and used --force. And then you were surprised that wha…
It still is a broken design that you can ever lose history or hose a repository in a tool that is designed to store history, forever. That's a sharp edge that should be exposed, and its not the only one in git.
Earlier quoted context omitted.
you list, move, rename and delete branches with branch, but create branches using checkout? Seriously??? git checkout -b new-branch ... is a shortcut for: git branch new-branch git checkout new-branch You can create the branch or otherwise manipulate it without actually checking it out, so it's useful to have it separate and have a shortcut. (I agree that git's interface is terrible, but I disagree that this is one o…
> but I disagree that this is one of those cases I do think this is precisely one of those cases. "Branch" is a major, repo-modifying operation; "checkout" is a trivial context switch operation. The user interface disaster here was that the major operation is treated as subservient to the trivial operation. It should be the other way around. Therefore, the shortcut for creating a branch and switching to it should be…
Well. Actually you are using git in place where svn or rsync should be enough. Just look at git.kernel.org - over 400 repos only for linux kernel. This is what git designed for - to be Mass Distributed Version Control System. So are using it as tape archiver and wondering why defaults look so unfrendly.
Code section 5 and 6 are apparently modifying the code branch, and the pages branch, respectively, but doing so in separate local clones of the repo. I think there's a typo in code section 6, where I think he meant to start with
cd ../die-git-die.pages
Looks like it was inspired by a hackernews comment https://news.ycombinator.com/item?id=2684483 and it replaces these commands
I don't know why, but I always end up telling every single person who either 1) Bitches about git, or 2) asks for help, that I always, always, always tell "git push" or "git pull" which remote and branch. It's muscle memory and makes everything more explicit and easy to understand. Although, in this case, it sounds like you expect git to be intuitive. (Which it is not) So this basically amounts to a blog post complai…
From my experience, git pull origin branch didn't do what I expected. (Pulling from the remote branch to the current branch.) I haven't figured out what it does, so I just use git fetch then merge. :(
EasyGit also provides better built-in documentation. For example, if you get merge conflits, `eg status` will mention that you can run `eg help topic middle-of-merge`. That command opens a page explaining your options – how to find conflicts, resolve conflicts, etc. I have found EasyGit very useful, and when it’s installed, I always use `eg` instead of `git`. You can download the EasyGit script at the linked website, or install it using Homebrew with `brew install easy-git`.