7 ms·

While a lot of tutorials mention how complicated git is in contrast to mercurial I - being a git native - feel the other way around. Git is intuitive with a sma

by wirrbel 13y ago

While a lot of tutorials mention how complicated git is in contrast to mercurial I - being a git native - feel the other way around. Git is intuitive with a small number of concepts necessarry to grasp my whole workflow. Using this workflow with mercurial is really frustrating when I do it - the occasional pull request for a python-based project. A git branch as a concept is really simple, the mercurial ways I just cant wrap my head around (granted I only use it occasionally). As a platform I like how all the porcellain in mercurial is implemented in a high level python. I can only wonder how productive writing custom porcellain commands in mercurial is given that interface.

jordigh 13y ago
> I can only wonder how productive writing custom porcellain commands in mercurial is given that interface. You don't have to use Python to add more commands on top of Mercurial. Its CLI is also its API, just like git, and you don't typically have to use Python to write tools on top of hg, just like you don't typically need to write C to hack on top of git. The stdout of hg is guaranteed to remain stable, so you can script it by just parsing stdout. The options are guaranteed to remain stable, so your old tools won't need to be updated in case hg's CLI some day changes, because its CLI never changes. There are also a bunch of hg CLI commands that start with debug (e.g. hg debugparents or hg debugdag) that you can use to directly manipulate hg's internal revlog data structure and do fun things like create a corrupt repo, if that's what you want to do. :-)
- wirrbel 13y ago
  I probably should have phrased this more clearly: I think that a python interface (or any other high level script interface) is the more convenient way for a programmer to extend or write hooks/extend the dcvs (I am now thinking about pre commit or post commit hooks in git, etc.). Any first hand experiences with this?
  - jordigh 13y ago
    Sure. Here is a silly example that adds a lol() revset to Mercurial that fetches all prime revision numbers: http://inversethought.com/hg/revset/file/2ddbf1893f3b/lol.py http://inversethought.com/hg/revset/file/2ddbf1893f3b/lol.py
hugi 13y ago
As with most software, it probably depends largely on what you're used to. I started my distributed SCM life in Mercurial (moving from svn) and found it to be fast, simple and friendly to use. Being an experienced Mercurial user, I hated git when I first started using it - changing something as core to one's development life as the SCM isn't easy. But after a while of working with both, you start seeing git and hg as relatively equal products, just with different UI quirks. I eventually moved most of my projects to git, though. Not because I thought it was better, but because it was more widely used. And being the collaborative type, using git was the path of least resistance.
gecko 13y ago
There are two things people mean when they say Git is complicated. Some people mean that Git's model is complicated, which what you're talking about. I actually find its model very simple, some people find it complicated, but at any rate, I certainly think Git and Mercurial have comparable complexity in the model. What most people mean, though, is that Git's UI is complicated. To be blunt, I think this is simply objectively correct. For example, "git checkout foo" might mean go to the foo branch, or might mean revert a file called "foo". There is no way to know. If you want to be sure to revert a file called foo, you can do "git checkout -- foo", I believe, but I don't know a branch equivalent (and it at any rate won't be symmetrical). Want to create a new branch? That's "git checkout -b newbranch". Want to delete it? That's "git branch -d newbranch". There are tons of things like this in the Git UI, where commands have basically arbitrary parameters in different contexts. Way back when Git was first created, the plan was for what is now called Git to be the underlying implementation of a higher-level UI. I really, profoundly wish that had actually panned out. Instead, Git's low-level commands gradually grew more user-friendly until it hit the "good enough" zone. That's what people usually mean when they say Git's complicated.
- __david__ 13y ago
  I feel that people that rail on "git checkout" don't actually understand what it does. It does two things: 1) unpacks files from the repository into the working directory, and 2) updates the current working branch. Want to revert your changes? That's unpacking from the repo to the working dir. Want to switch to a different branch? That's also unpacking files from the repo to the working dir. The only difference is that in one case the current working branch stays the same and in one case it changes (or you could look at it as in one case you set it to the current value and in the other you set it to something different). This is why people say you need to understand the underlying model of git to grok it. The commands make perfect sense from the perspective of the data model. Also, want to create a branch? "git branch new-branch". Delete it "git branch -d new-branch". The "checkout -b" is an optimization, just like "rm -r x" is an optimization of "find x | xargs rm" (why do two commands when you can do one?). The only thing I don't like about git UI is that it can't decide what to call the "index". It's called "index", "staging area", and "cache" in various places (including command line flags), which is confusing.
ColdHawaiian 13y ago
The key concept that you need to truly understand how Git works is to just remember that Git is just a tree of commits, with temporary and movable Post-it notes attached. (The Post-it notes representing branches and other references).
- mrtngslr 13y ago
  That's a good image. The key difference to Mercurial is then that Mercurial's tree of commits don't need Post-it notes. The tree can stand on its own without extra branch labels. You can add them (see bookmarks) but they're an optional feature.
nnethercote 13y ago
> Git is intuitive with a small number of concepts necessarry to grasp my whole workflow. http://jordi.inversethought.com/blog/on-gitology/ http://jordi.inversethought.com/blog/on-gitology/ explains git's complexity extremely well (without even getting into horribleness of the command line UI). The following is a key quote, though you should read the whole thing. The following gitological concepts are not particular to git: * repositories (repos) * commits or changesets (csets) * directed acyclic graph (DAG) * branches * pushing and pulling changes * whole-repo tracking, not individual files * rebasing csets * pushing and pulling csets The following are purely gitological and add unnecessary complexity, in addition to eventually being unavoidable: * Exposing the index/staging area * Exposing other implementation details: blobs, trees, commits, refs * refs and refspecs * Branches are refs * Detached HEADs (a.k.a “not on a branch”) * Distinguishing remote and local tracking branches * Choosing which branch to pull onto * Bare repos * Hard, soft, mixed resets * Porcelain vs plumbing
wirrbel 13y ago
Kind of sad how this post seemd to have resonated mostly for its reference to git, I intended (and failed) to point out my questions on mercurial. As a git user, I see one of the main features for mercurial: As it is in python, it can be used as a library. This should make tooling and cool developments so much easier for the average developer who is not a shell script person.

by wirrbel 13y ago

jordigh 13y ago

> I can only wonder how productive writing custom porcellain commands in mercurial is given that interface. You don't have to use Python to add more commands on top of Mercurial. Its CLI is also its API, just like git, and you don't typically have to use Python to write tools on top of hg, just like you don't typically need to write C to hack on top of git. The stdout of hg is guaranteed to remain stable, so you can script it by just parsing stdout. The options are guaranteed to remain stable, so your old tools won't need to be updated in case hg's CLI some day changes, because its CLI never changes. There are also a bunch of hg CLI commands that start with debug (e.g. hg debugparents or hg debugdag) that you can use to directly manipulate hg's internal revlog data structure and do fun things like create a corrupt repo, if that's what you want to do. :-)

wirrbel 13y ago
I probably should have phrased this more clearly: I think that a python interface (or any other high level script interface) is the more convenient way for a programmer to extend or write hooks/extend the dcvs (I am now thinking about pre commit or post commit hooks in git, etc.). Any first hand experiences with this?
- jordigh 13y ago
  Sure. Here is a silly example that adds a lol() revset to Mercurial that fetches all prime revision numbers: http://inversethought.com/hg/revset/file/2ddbf1893f3b/lol.py http://inversethought.com/hg/revset/file/2ddbf1893f3b/lol.py

hugi 13y ago

As with most software, it probably depends largely on what you're used to. I started my distributed SCM life in Mercurial (moving from svn) and found it to be fast, simple and friendly to use. Being an experienced Mercurial user, I hated git when I first started using it - changing something as core to one's development life as the SCM isn't easy. But after a while of working with both, you start seeing git and hg as relatively equal products, just with different UI quirks. I eventually moved most of my projects to git, though. Not because I thought it was better, but because it was more widely used. And being the collaborative type, using git was the path of least resistance.

gecko 13y ago

There are two things people mean when they say Git is complicated. Some people mean that Git's model is complicated, which what you're talking about. I actually find its model very simple, some people find it complicated, but at any rate, I certainly think Git and Mercurial have comparable complexity in the model. What most people mean, though, is that Git's UI is complicated. To be blunt, I think this is simply objectively correct. For example, "git checkout foo" might mean go to the foo branch, or might mean revert a file called "foo". There is no way to know. If you want to be sure to revert a file called foo, you can do "git checkout -- foo", I believe, but I don't know a branch equivalent (and it at any rate won't be symmetrical). Want to create a new branch? That's "git checkout -b newbranch". Want to delete it? That's "git branch -d newbranch". There are tons of things like this in the Git UI, where commands have basically arbitrary parameters in different contexts. Way back when Git was first created, the plan was for what is now called Git to be the underlying implementation of a higher-level UI. I really, profoundly wish that had actually panned out. Instead, Git's low-level commands gradually grew more user-friendly until it hit the "good enough" zone. That's what people usually mean when they say Git's complicated.

__david__ 13y ago
I feel that people that rail on "git checkout" don't actually understand what it does. It does two things: 1) unpacks files from the repository into the working directory, and 2) updates the current working branch. Want to revert your changes? That's unpacking from the repo to the working dir. Want to switch to a different branch? That's also unpacking files from the repo to the working dir. The only difference is that in one case the current working branch stays the same and in one case it changes (or you could look at it as in one case you set it to the current value and in the other you set it to something different). This is why people say you need to understand the underlying model of git to grok it. The commands make perfect sense from the perspective of the data model. Also, want to create a branch? "git branch new-branch". Delete it "git branch -d new-branch". The "checkout -b" is an optimization, just like "rm -r x" is an optimization of "find x | xargs rm" (why do two commands when you can do one?). The only thing I don't like about git UI is that it can't decide what to call the "index". It's called "index", "staging area", and "cache" in various places (including command line flags), which is confusing.

ColdHawaiian 13y ago

The key concept that you need to truly understand how Git works is to just remember that Git is just a tree of commits, with temporary and movable Post-it notes attached. (The Post-it notes representing branches and other references).

mrtngslr 13y ago
That's a good image. The key difference to Mercurial is then that Mercurial's tree of commits don't need Post-it notes. The tree can stand on its own without extra branch labels. You can add them (see bookmarks) but they're an optional feature.

nnethercote 13y ago

> Git is intuitive with a small number of concepts necessarry to grasp my whole workflow. http://jordi.inversethought.com/blog/on-gitology/ http://jordi.inversethought.com/blog/on-gitology/ explains git's complexity extremely well (without even getting into horribleness of the command line UI). The following is a key quote, though you should read the whole thing. The following gitological concepts are not particular to git: * repositories (repos) * commits or changesets (csets) * directed acyclic graph (DAG) * branches * pushing and pulling changes * whole-repo tracking, not individual files * rebasing csets * pushing and pulling csets The following are purely gitological and add unnecessary complexity, in addition to eventually being unavoidable: * Exposing the index/staging area * Exposing other implementation details: blobs, trees, commits, refs * refs and refspecs * Branches are refs * Detached HEADs (a.k.a “not on a branch”) * Distinguishing remote and local tracking branches * Choosing which branch to pull onto * Bare repos * Hard, soft, mixed resets * Porcelain vs plumbing

wirrbel 13y ago

Kind of sad how this post seemd to have resonated mostly for its reference to git, I intended (and failed) to point out my questions on mercurial. As a git user, I see one of the main features for mercurial: As it is in python, it can be used as a library. This should make tooling and cool developments so much easier for the average developer who is not a shell script person.