41–50 of 100 posts
"The git, the?" But seriously, yes, you have to learn how to use Git in order to use Git. But you don't have to use Git. Click here to renew your Visual Source Safe license, or better, just copy your file to file.1 every time you edit it. No way that can go wrong!
And feminine, at that?
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.
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…
That's a sharp edge that should be exposed, and its not the only one in git.
Earlier quoted context omitted.
It's a problem of user interface design. Git's user-machine interface does not follow the principle of least astonishment. It's not orthogonal. Functionality is grouped in very strange ways (you list, move, rename and delete branches with branch, but create branches using checkout? Seriously???). And don't even get me started on the nightmare that is submodules. The whole thing reminds me of the bad old unix days of…
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…
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
git branch -c new-branch
Earlier quoted context omitted.
It's a problem of user interface design. Git's user-machine interface does not follow the principle of least astonishment. It's not orthogonal. Functionality is grouped in very strange ways (you list, move, rename and delete branches with branch, but create branches using checkout? Seriously???). And don't even get me started on the nightmare that is submodules. The whole thing reminds me of the bad old unix days of…
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…
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
> $ git push origin gh-pages I think that if you had changed the above to $ git push -u origin gh-pages then everything else would have gone smoothly.
This is what I do personally. We also use rebases liberally at my office which requires us to force push upstream. On-boarding new team members scares the shit out of me.
Moreover, any loss that does occur is recoverable as long as you keep your clone around. Git doesn't garbage collect refs for at least 30 days. So you're pretty protected if you clone to a location that has regular backups.
Whenever I'm pulling down code, instead of `git pull', I use fetch. I fetch the specific branch into the local remote tracking branch (remote/branchname). Then use rebase, rather than merge. I won't lose anything and it avoids those dumb merge commits. Also, aliases are great for this. git fetch :refs/remotes/ / git rebase /
git branch -r