5 ms·

Git as source control. I am absolutely in love with Git and wouldn't want to go back to anything else. I've used CVS, Subversion, Perforce, Mercurial and now Gi

Git as source control. I am absolutely in love with Git and wouldn't want to go back to anything else. I've used CVS, Subversion, Perforce, Mercurial and now Git and I never knew what I was missing until I got to git!

etherael 16y ago
As someone who has tried mercurial and are now firmly in the git supporters camp, can you relate how git is superior to mercurial? I've used git for a long time now and I really like it, but it's very hard for most developers to wrap their heads around and it seems like mercurial has a better cross platform toolchain than git, these things have made me frequently ponder how mercurial compares to git.
- X-Istence 16y ago
  What I like about Git over Mercurial is some stuff that may seem weird to others. - The octopus tree merge, I use it much more than I previously thought I did looking at some of my non-public repositories. - having branches that have completely different history (never did figure out how to do this with Mercurial) - read-tree, filter-branch, and a whole range of other tools to re-write history or change somethings location and all that fun jazz. - tracked branches, makes git push/pull easier - the staging area and being able to select different parts of a patch to commit separately (This is by far one of the most important ones) - amending a commit, rebasing and altering history isn't just supported it is recommended, and makes commits from multiple different sources look much cleaner in a tree view (more linear history). This is definitely great in a company where mainline may move fairly fast and rebasing by developers is a way to have the history look linear, without merging "master" into a feature branch. - Git has support for short-lived play branches, Mercurial has this as well with hg strip, but it is an extension and not part of the core, or you have to clone a full repository, makes working with others harder too as I can't just push the play branch up to my clone on the server (assuming a Github model). I've found that once I realised how Git works under the hood that it made so much more sense, not only that I feel that it is more powerful, for example here is a gist of something I recently did for a repo at work: https://gist.github.com/878192 https://gist.github.com/878192 This helps with other internals projects in that we are not pulling in the full "master" branch, instead we are just pulling in a very specific sub-set of files, which is easy to keep updated with git pull -s subtree. I'm sure that I have only touched the least significant parts of what Git has to offer, and that there is so much more waiting for me, but that is my reasoning and why I like it so much.

etherael 16y ago

As someone who has tried mercurial and are now firmly in the git supporters camp, can you relate how git is superior to mercurial? I've used git for a long time now and I really like it, but it's very hard for most developers to wrap their heads around and it seems like mercurial has a better cross platform toolchain than git, these things have made me frequently ponder how mercurial compares to git.

X-Istence 16y ago
What I like about Git over Mercurial is some stuff that may seem weird to others. - The octopus tree merge, I use it much more than I previously thought I did looking at some of my non-public repositories. - having branches that have completely different history (never did figure out how to do this with Mercurial) - read-tree, filter-branch, and a whole range of other tools to re-write history or change somethings location and all that fun jazz. - tracked branches, makes git push/pull easier - the staging area and being able to select different parts of a patch to commit separately (This is by far one of the most important ones) - amending a commit, rebasing and altering history isn't just supported it is recommended, and makes commits from multiple different sources look much cleaner in a tree view (more linear history). This is definitely great in a company where mainline may move fairly fast and rebasing by developers is a way to have the history look linear, without merging "master" into a feature branch. - Git has support for short-lived play branches, Mercurial has this as well with hg strip, but it is an extension and not part of the core, or you have to clone a full repository, makes working with others harder too as I can't just push the play branch up to my clone on the server (assuming a Github model). I've found that once I realised how Git works under the hood that it made so much more sense, not only that I feel that it is more powerful, for example here is a gist of something I recently did for a repo at work: https://gist.github.com/878192 https://gist.github.com/878192 This helps with other internals projects in that we are not pulling in the full "master" branch, instead we are just pulling in a very specific sub-set of files, which is easy to keep updated with git pull -s subtree. I'm sure that I have only touched the least significant parts of what Git has to offer, and that there is so much more waiting for me, but that is my reasoning and why I like it so much.