"Fundamentally, the way (most) people learn and think about subversion is different from the way git experts think about git. subversion’s internal model is fairly complex, but you are not expected to understand it. You just have to know the half dozen commands you’ll ever need, and you use them, and everything is fine.
Git’s model is fundamentally fairly simple (a DAG of immutable commit objects where branches are named mutable pointers into it), but you are expected to understand it fully to use git effectively."
...
" The other, perhaps more fundamental reason, is that git is designed to be infinitely flexible, and so it’s fairly rare that you can give an answer for “How do I do X with git?”, since the answer will often depend on, “Well, what are your project’s conventions?” "
Part of why I like git is the lack of abstraction. Lack of abstraction means the abstraction that isn't there can't leak. I've done some bizarre things in git, mostly induced by the fact the company I'm working for is still on SVN in the core. For instance, on two fundamentally different machines based on the same source tree, I developed a shared feature on one, bundled it all up into one commit, put some work into integrating it on the other, put some more work on the original and bundled it up into one new unified commit, pulled from the second machine and did an interactive rebase to slide the new megacommit under the integration commits. And it all worked perfectly and exactly as I expected, complete with dead-on accurate merge conflicts that truly were conflicts. If you had problems following that description, well, git didn't.
Yes, to the extent that may seem like a bizarre workflow, it is. I know. There are additional constraints I did not describe. The point is, it's a workflow that git doesn't close off with leaky or over-limiting abstractions.
That said, I totally agree that this is irreducibly a strength and a weakness at the same time, and YMWV. But I'm glad it's around so I can use it. It's saved my bacon more times than I can count.
I do think git is better than mercurial in significant ways, at least how it was circa 2010:
- tag handling in hg is (was ?) horrible
- I think using integers for revisions, even if just in the UI is a very confusing feature, as it gives a false sense of familiarity (hg like every DVCS I know internally uses unique ids for revisions).
- too many ways to do branching that all have +/-. While you can do it in a similar way to git, you don't have all the UI that makes it so useful.
- the notion of tip is a major UI wart as well.
On the + for mercurial: definitely better support for cross platform, more consistant UI, better performances on windows.
I think there are tons of reasons to prefer Mercurial over git (ease of use on Windows in the early days being a big one). I also think there are a smaller number of potentially more significant reasons to prefer git.
But I think it's almost completely impossible to separate the success of Git from the tools ecosystem. I really think Mercurial would have been at least as popular as git in the long run if it had something as good as Github behind it from the beginning.
Which then makes me wonder why they chose to start GitHub instead of HgHub. Rails may have been the reason; I'm not sure when or why Rails started using git.
I suspect something in the magic of the execution of github has also helped a lot. Maybe it's the strong focus on social ontop of code and storage or something else but that site has probably helped a lot.
Then again, even before that many big projects were falling to git from the likes of svn like Xorg and others. So it's hard to say.
Maybe going back to the mailing lists of some of the big conversations might help shed more light.
But yes, usually what can make a piece of software great is having some good applications, and the linux kernel was a great place for git to grow up and show off on. Maybe mercurial just suffered from less of that. Mind share seems to grow exponentially.
I don't know how active the Mercurial mailing list is, but the git mailing list was hugely active when I was on it back in 2008/2009. I can only imagine that it's gotten bigger over time. I imagine that to some extent that had at least something to do with it (though I don't claim that it was 100% of the cause).
If you wish to do something like import a large svn project you will find that git is dramatically faster and doesn't require you to build/acquire svn with swig bindings.
The problem with git wrappers is that there are a dozen of them but none have critical mass, so all docs and examples are written in terms of bare git. It's like CoffeeScript — it's fine if you already know JS and use it to save time, but you can't use it as a way to avoid learning JS.
Interesting. Yeah, I was afraid that was the case. I'm starting my own wrapper for better or worse. Maybe I'm just being blindly naive. https://github.com/dogweather/g
I'm attempting to first spec it out in an appropriate way: writing the docs first, and so that the new abstraction is maintained. However, the new commands should re-use git command knowledge and not change it arbitrarily. It should fail well.
Which is why I'm a bit saddened to see another wrapper start up. Does OP even know about them, or does he think he's the first person to have the idea of creating a git porcelain?
And then there's always that 1 time you need to do something that git can do, but your porcelain can't. Then you have no choice but to learn git the 'right' way.
Personally, I think I understand git too well for picking up a porcelain to be useful to me, which also makes me a bit sad.
I admit it - I don't know about any other higher level command line wrappers. I've only found hub http://defunkt.io/hub/ which isn't exactly what I'm thinking of.
Is Git really that hard to use? I've used ClearCase, Perforce, CVS, SVN, and Git. They all have their benefits and idiosyncrasies. Git is not that hard. I do have to search for its usage and example from time to time for less frequently used commands, but that's the same for the others.
The problem with git is that its defaults are suited to large teams collaborating. For example if you create tags then push won't push them unless you specify another flag. This makes sense when there are lots of collaborators (you don't want everyone's tags polluting) but is annoying in small groups (you do want to share). This isn't to fault git, but it is what makes it harder to use.
I'm also confused by the github love. Exactly what is it that people think is so good about it? The ticket tracker is terrible (no prioritization, no attachments), the wiki doesn't have table of contents/document structure, you can't cross link between projects etc. As an example Google Code does quite a bit better on those issues, and they let you have multiple repositories per project so you can share the wiki, tracker and downloads as makes sense.
I have been using UNIX-type operating systems almost exclusively for the whole of my professional life so have zero appreciation for the troubles people have when approaching UNIX tools from a Windows (or whatever) mindset.
Git (and the whole toolchain and OS for that matter) is much more about DWIS than DWIM and that does not click for a lot of people.
He's saying that your intention is to use this tool to rename a file, in-place, but the implementation of this tool is `mv` which is supposed to be for "moving" files around in the filesystem, so the implementation is leaking into and clashing with the user interaction.
because he was thinking of doing a rename he expected:
mv /path/to/{old_name,new_name}
to happen.
For people with a mental model of files and directories built from using a GUI with windows and folders this does seem to be implementation leakage since you have to know that renaming is moving because of "how the filesystem works". They think of the file name as file metadata and the file contents as the file.
If you have a mental model built around unix-y file management then you probably think of the file path as the file and the fact that renaming and moving are the same thing seems obvious.
requires yet another mental model, that of a shell and globbing. I've been using UNIX/Linux for 20 years and that still trips me up - because I started in an OS with no shell.
As much as I agree with the rest of the article, I have no idea what is meant by this "implementation leakage". Relative and absolute paths are a part of the fundamental Unix interface.
I think the implementation leakage is the fact that mv is used for renaming files. Windows has "move" and "ren", where the latter works the way the author would like.
> REN [drive:][path]filename1 filename2.
> Note that you cannot specify a new drive or path for your destination file.
But yes, for this discussion, a higher level version would probably split it into two commands: rename and move. And these would only do those particular functions. With that there is no implementation leakage. For the few times that you'd want to move and rename, you'd need to use both commands.
In the project's README it says "g add isn't necessary for staging since g commit will automatically add objects. In fact, g does not expose the concept of staging through its interface", which if followed through with will ensure that this project never gains traction.
The staging areas, though foreign to newcomers, is one of the most liked features of git (I should look up the git survey results, but I'm lazy). In fact, it is core to many excellent features of git, not least of all the ability to interactively select which parts of your work you want to commit, even down to different hunks in the same file. Ignoring this powerful concept makes git a less powerful beast, and hobbles it unnecessarily. To say that the concept of staging is complex is fine, but surely throwing it out is the wrong answer.
I started off with that idea because I personally rarely use this feature. I pretty much always commit all my changes. And so I only change things that I want to commit.
I'm sure I picked up this habit from my svn days. I'll look around for those survey results.
We seek to fix the abstraction aspect by focusing on the difficult of collaboration. It's working really well for us. We'll be launching our beta test soon.
The author suggests aliases and while I use aliases daily, I don't believe that will solve the problem he references. I think providing a better mental model for what exactly git is doing through visual metaphors is the biggest help to those learning git. I've found something as simple as the chart here to help explain the concepts of adding and staging http://gitready.com/beginner/2009/01/18/the-staging-area.htm...
Git is a Hole Hawg, just like UNIX. That's intentional. Stop trying to change the software to be easier. Instead change yourself. Make yourself stronger and better by learning this complicated stuff, and become a master.
You can't drive a car with a manual, the solution isn't to get an automatic. The solution is to learn to drive stick.
I think I take your point, but we should only put up with having to learn necessarily complicated things. So to the extent that the Git interface reflects a powerful and flexible internal model, I'm with you. But Git is also unnecessarily complicated. The commands are inconsistent and hard to remember until you have them by rote. That's a failure of software design.
Great story about the Hole Hawg, but... I've had two houses built. For about five years, I spent 8-12 hours a day with some of the best contractors in Massachusetts.
I never saw a Hole Hawg.
I kinda wonder if that's the story you tell yourself to explain why you were hanging in midair from a drill.
"Fundamentally, the way (most) people learn and think about subversion is different from the way git experts think about git. subversion’s internal model is fairly complex, but you are not expected to understand it. You just have to know the half dozen commands you’ll ever need, and you use them, and everything is fine.
Git’s model is fundamentally fairly simple (a DAG of immutable commit objects where branches are named mutable pointers into it), but you are expected to understand it fully to use git effectively."
...
" The other, perhaps more fundamental reason, is that git is designed to be infinitely flexible, and so it’s fairly rare that you can give an answer for “How do I do X with git?”, since the answer will often depend on, “Well, what are your project’s conventions?” "