Earlier quoted context omitted.
emacs is moving off of bzr.
[deleted]
git is GPLv2 not GPLv2-or-any-later-version.
Prefer mercurial to git
21–30 of 189 posts
Re: Prefer mercurial to git
#22I've been meaning to do a blog post about this for a while, but I've tried both, and so far, I prefer Git because of the way it treats branches. Git seems far friendlier to the workflow of just doing stuff, and deciding how you want to commit it later. In Git, it's easy to work for a while, then decide you have 3 commits worth of changes, and one of them really ought to be in its own branch, and commit it all like that. The code that you branched off stays out of your mainline for now, but is easy to switch back to and work on some more. At any time, you can easily delete the branch, and it all effectively disappears, push it somewhere else for somebody else to work on, or merge it back into main when it's ready. Well, merging might be tricky if you wait too long, but you get the idea.
Where Mercurial falls short to me is that if you create a branch in your main repository like that, then it never goes away as far as I can tell. What Mercurial really wants you to do is clone your repo, and do that work that would be a Git branch in the clone. But to do that, you have to start with a clean repo, actively decide you want to create a new branch/clone, clone your repo, and only then start doing that work in the clone. If you've already done some work, and then decided that a piece of it ought to be branched off, then your workflow is pretty messy - you have to clone with the work uncommitted, then manually move the changes over to the clone and commit them there. And switch any working directories you might have open to the clone directory to work in it.
Yeah, no thanks, I'll stick with Git.
Re: Prefer mercurial to git
#23Re: Prefer mercurial to git
#24You should have linked the first post in that thread. It explains what the whole thing is actually about: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00... Tl;dr: Mercurial is a free software project sharing GNU's goals, while Git is made by anti-GNU people who do not believe in free software and has an incompatible license.
>while Git is made by anti-GNU people who do not believe in free software and has an incompatible license.
WTF? Git is GPLv2 - the exact same as the Linux kernel. A great many developers are avoiding v3 due to the changes it made. And "anti-GNU people" is just a lame insult.
Re: Prefer mercurial to git
#25You should have linked the first post in that thread. It explains what the whole thing is actually about: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00... Tl;dr: Mercurial is a free software project sharing GNU's goals, while Git is made by anti-GNU people who do not believe in free software and has an incompatible license.
Summary of main arguments:
Jordi Gutiérrez Hermoso:
[...] main argument in favour of hg is not technical, but
rather social. For GNU, I think it is far more important
to support a project that aligns with GNU's aims [...] GPL2+
+1. And I say that as someone who *likes* hg and wishes
it had won. Repeating the bzr mistake would be stupid, stupid, *stupid*.
The discussion evolved in the meantime, so it's probably better to read the thread yourself: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00...
Re: Prefer mercurial to git
#26My biggest issues with hg are that hg's revision numbers aren't synchronized across instances, they are local only[1] making them kind of useless, you can't easily have local branches[2], and it stores changesets instead of objects. I've ever seen a convincing argument to choose hg over git. Sure you can do a lot of things with it and I'm sure it's perfectly fine to use, but if you know git, and you like git, there's…
> What does hg have that makes it better than git that you should give up git? Better user experience out of the box for Windows shops. This might change with Microsoft's adoption of git for TFS, but you won't find many appraisals for git at my workplace. Many people still miss hg.
You mean tortoiseHG? There's tortoisegit as well. And the first Windows-only proprietary client I could find supports both systems (Smartgithg: http://www.syntevo.com/smartgithg/)
Re: Prefer mercurial to git
#27I was forced to use mercurial for a few years at work and I really hated it. Sure it has a better learning curve than git (or did) but I found it to be incredibly frustrating already knowing git. In addition, I found it to be slower, less flexible, and prone to permanent repository corruption - yes, in git you do see repo corruption but because of the cryptographic nature of git objects you know immediately. HG will…
I'm interested in your comment about the cryptographic nature of git objects. I know that hashes are used to identify commits, but I'm not sure how Git uses cryptography elsewhere — e.g. to check the integrity of repos, as you said. Can you explain this aspect in more detail? (Not being argumentative; just curious.)
Committers are able to sign their commit with their GPG key.
Edit: I was wrong and changed all the words
Re: Prefer mercurial to git
#28I was forced to use mercurial for a few years at work and I really hated it. Sure it has a better learning curve than git (or did) but I found it to be incredibly frustrating already knowing git. In addition, I found it to be slower, less flexible, and prone to permanent repository corruption - yes, in git you do see repo corruption but because of the cryptographic nature of git objects you know immediately. HG will…
I'm interested in your comment about the cryptographic nature of git objects. I know that hashes are used to identify commits, but I'm not sure how Git uses cryptography elsewhere — e.g. to check the integrity of repos, as you said. Can you explain this aspect in more detail? (Not being argumentative; just curious.)
Every object in the repository, including commits and trees, is hashed via SHA-1. Commits also include the SHA of the previous commit, so if you verify each commit, then compare the SHA at the top to the "correct" one, then that means your entire repository is valid.
Re: Prefer mercurial to git
#29Earlier quoted context omitted.
I'm interested in your comment about the cryptographic nature of git objects. I know that hashes are used to identify commits, but I'm not sure how Git uses cryptography elsewhere — e.g. to check the integrity of repos, as you said. Can you explain this aspect in more detail? (Not being argumentative; just curious.)
Committers are able to sign their commit with their GPG key. Edit: I was wrong and changed all the words
Not by default it isn't. And git uses GPG, not SSH keys.
Re: Prefer mercurial to git
#30I've been meaning to do a blog post about this for a while, but I've tried both, and so far, I prefer Git because of the way it treats branches. Git seems far friendlier to the workflow of just doing stuff, and deciding how you want to commit it later. In Git, it's easy to work for a while, then decide you have 3 commits worth of changes, and one of them really ought to be in its own branch, and commit it all like th…
or just use bookmarks and enjoy the exact same workflow as git.