Sanjoy Mahajan wrote: > The car analogy is excellently clear. > >> they need more than the "stupid simple" git usage, but if they don't >> need the extreme power of git, Hg is simpler for people to learn how >> to use. > > As a 80%-hg/20%-git user, I'm curious what features of git you had in > mind, so I know where to look as I wander up the git learning curve. > > My experience with the git user interface, for what it's worth, is > that I never quite get the conceptual model crystal clear enough in my > head. So it won't stay for long enough for me to progress up the > learning curve and retain the gains. I move up a bit, but the gain > soon evaporates and I backslide, and then just hack my way through it. > > I found hg's conceptual model very easy to learn, almost as if I don't > have to remember anything. Maybe that simplicity comes at a price, > whence my question at the start about the extreme-power features of > git. As I never used Mercurial (hg), only read a bit about it and discussed on #revctrl, I cannot say what features git has that hg has not, but I can tell what powerfull git features differ from other SCM. First, usually in other SCM the concept of branch is closely tied to the concept of repository, perhaps allowing to share storage between branches on the same local filesystem (on the same machine). In git, repository holds DAG, the graph of revisions (of versions). Branches are "only" ways to access this graph, and to extend it of the new commits. This makes git more powerfull, but also perhaps unnecessary complicated if you deal with single-branch repositories, or few-branch case. Additionally this "complication" makes very clean model of repository - but you have to understand it... Second, the index. One might think that it is performance hack, but it allows for commiting changes piece by piece and, what is more important, a place form making merge in. Cogito (alternate Git UI/porcelain) tries to hide index. By the way, I wonder how hg does merges without index to provide place where do merges in... Third, explicit/on-demand packing. This allows for the most (I think) compression of all SCMs, and for the wire format to be the same as on-disk format (with the addition that you can send thin packs on wire). As of now no porcelain tries to hide it, although with the latest work allowing for historical packs it would be easy to add this without significantly affecting preformance. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html