31–40 of 122 posts
Love the concept of the article but right out of the gate comparing it to a Model T and saying you must be a mechanic to operate it will likely result in a high bounce rate, and possibly just serve to re-affirm someones belief that git is, indeed, complex.
If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you have a strong mental model of how git works, and this is how the author of the article got into trouble. It's possible to build a very successful git workflow using only the following commands: git clone git:... git add path/to/new_file git commit -a git pull gi…
Why the -u on push?
If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you have a strong mental model of how git works, and this is how the author of the article got into trouble. It's possible to build a very successful git workflow using only the following commands: git clone git:... git add path/to/new_file git commit -a git pull gi…
Why the -u on push?
If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you have a strong mental model of how git works, and this is how the author of the article got into trouble. It's possible to build a very successful git workflow using only the following commands: git clone git:... git add path/to/new_file git commit -a git pull gi…
Why the -u on push?
-u, --set-upstream
For every branch that is up to date or successfully pushed, add upstr
eam (tracking) reference, used by argument-less git-pull(1) and other
commands. For more information, see branch..merge in git-config
(1).
Having used Mercurial and Git, I have to say I vastly prefer the interface of Mercurial. It still has its quirks, but overall I find it much easier to use, especially on Windows. Git was very clearly built as a Unix solution first, with Windows support hacked on later.
No, actually, it's not. And that post proves it. You can do some things to make it easier on yourself (and others) but it's not simple. You find out how un-simple it is when you hit one of those magical corner cases. Don't get me wrong, I love Git. I far prefer it over SVN and CVS. But it's not simple.
I think the author's point is that the git internals (i.e. the .git folder) are simple; I don't think the author is disputing that the commands sitting on top of the git internals are sometimes horribly complicated. The fact that the contents of the .git folder can be explained in ~2000 words (10 min of reading) is impressive--this would be impossible with a more complicated data model. FWIW, compare: http://www.goog…
If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you have a strong mental model of how git works, and this is how the author of the article got into trouble. It's possible to build a very successful git workflow using only the following commands: git clone git:... git add path/to/new_file git commit -a git pull gi…
Trying to use rebase the same week or month that you learn git (or version control period), while doable for some, is just crazy for everyone else. You don't jump into riding a bike before you learn to walk.
If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you have a strong mental model of how git works, and this is how the author of the article got into trouble. It's possible to build a very successful git workflow using only the following commands: git clone git:... git add path/to/new_file git commit -a git pull gi…