> you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.
It's concise (the linked article is gigantic) and allows for an understanding of this overhyped user hostile DVCS. I know that git won but don't expect me to be happy about it.
I found this tutorial (the one you recommend) to be, generally, terrible. It doesn't define terms, but rather just jumps into the git terminology without explaining things. For example the section on "Commit Objects" - what actually is a commit object? Is it a directory, is it a special file, is it .. something else? The term is used in an abstract manner without actually explaining what the term means - sure, it explains what is associated with the term, but why is it an object?
The same goes for the "Heads" explanation - its a reference to a commit object. Is this a softlink, is it a field in a special file that contains a reference .. what "is it?", and why is the word "head" used?
Whereas in the tutorial referred to in this article, "Git From the Inside Out", the terms are actually defined before they're used in any significant fashion. "Commit Objects = After creating the tree graph, git commit creates a commit object. This is just another text file in .git/objects/:" (with example), and .. "Heads = Which is the current branch? To find out, Git goes to the HEAD file at .git/HEAD and finds: ref: refs/heads/master This says that HEAD is pointing at master. master is the current branch."
I just want to point this difference out, because it actually is endemic in all Git tutorials I've found - either you define the basic terms, such that an association can be made in the mind of the reader, allowing them to grasp the abstractions .. or you don't. This appears to be a common problem with Git tutorials, in my opinion - the terms, or rather the taxology of the Git abstractions - are quite unclear. Why on earth the term "Head" is used to refer to a commit object is quite un-intuitive .. at first. Git really requires a deeper dive into the abstractions before surfacing for true understanding.
bzr. The CLI interface is much nicer and consistent. It has bound branches which is really useful useful when you are doing something small (see bsder comment above). You are not forced to use a staging area. There is no need to squash commits just to have a clean history instead you commit what you have and limit the depth of the log on view. Also, bzr is really easy to extend in Python. And so on and so on.
The git command line interface is the exact opposite of user friendly: some commands have options that fundamentally change the operation so much so it should be a different command: git reset removes changes from the index leaving your files intact and if you do not have anything staged then does nothing. Now, git reset --hard simply throws away your changes. This does not end here: git reset 'HEAD^' will remove a commit. How mad is that, git reset operates on the staging area but git reset something operates on commits??
git checkout filename is almost completely unpredictable as it might get the file from the index if it exists there or from HEAD if not. There is no indication at all what happened. And so forth.
Interesting, I've not ever seen a recommendation for bazaar over git or mercurial. I have heard that mercurial's CLI is a bit more sane than git, and I've also read that it's easier to extend in Python. How would you compare bazaar to mercurial?
I've actually only ever used git for professional and personal development, but I think I'll want to play around with both mercurial and bazaar now. Git's CLI is definitely a bit of a PITA.
Bazaar is basically unmaintained at this point. If you look on Launchpad, the trunk branch hasn't seen a commit since December 2014 [0]. There hasn't been a release since August 2013 [1].
Mercurial is very actively developed, with dozens of patches a month [2]. They also keep to a planned rolling release cycle [3] along with deep commitments about backward and forward compatibility [4].
New features like the experimental evolve extension [5] are also really cool. I use it for day-to-day work and find it incredibly useful for editing work-in-progress commits into nice self-contained patches.
Don't ask questions in an open forum if you aren't willing to accept with grace answers to your question from others, use email instead. Besides, his answer explained his position perfectly.
> you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.
It's concise (the linked article is gigantic) and allows for an understanding of this overhyped user hostile DVCS. I know that git won but don't expect me to be happy about it.