Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prefer mercurial to git

lists.gnu.org

Post reply on HN
Print view View original

41–50 of 189 posts

Re: Prefer mercurial to git

#41

Post by gcv »

frik wrote: post #25
copx wrote: post #6

You 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+ Reply by Eric S. Raymond: +1. And I say that as someone who *likes* hg and wishes it had won. Repeating the bzr mistake would be stupid, stupid, *stupid*. Edit: Raymond replied to Kastrup who…

You completely misquoted the replies. ESR was NOT replying to the OP, he was agreeing with a rebuttal of the OP's argument.

Re: Prefer mercurial to git

#42

Post by masklinn »

Hello71 wrote: post #28
hawkharris wrote: post #5

Earlier 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.)

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.

> Every object in the repository, including commits and trees, is hashed via SHA-1. Commits also include the SHA of the previous commit

mercurial does pretty much the same, as far as I know.

> so if you verify each commit

But surely that does not happen on every CLI operation does it? So you only find out about corruption when all the repository is traversed and checked, which will usually be explicitly or on clone. Thus the same as hg.

Re: Prefer mercurial to git

#44

Post by copx »

Karunamon wrote: post #24
copx wrote: post #6

You 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.

The people who avoid the GPL3 do it because they do not share the goals of the GNU project. The GPL3 expresses the same philosophy as the GPL2. GNU released a new version only because companies discovered a loophole (a bug if you will) in the GPL which allowed them to build non-free (as in GNU) systems based on GPL software. GNU was founded to fight such systems.

However, Linus Torvalds (Linux and git) has no problems with non-free at all and in fact wanted to support the production of such systems. Like many users of the GPL2 he never actually shared the goals of GNU.

Git's license was deliberately chosen to support the building of non-free systems. According to GNU ideology that is evil. If you are a GNU contributor you are not supposed to even link to non-free solutions. So yeah, of course the hardcore GNU ideologues do not like git or the people behind it.

Re: Prefer mercurial to git

#45

Post by masklinn »

ufmace wrote: post #22

I'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…

> 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.

`bookmarks` will do that. Or you can use unnamed heads and track them manually[0] (that's essentially what bookmarks — and git branches — do). "Detached heads" are not a thing in mercurial, heads don't have to be named.

[0] obviously there's nothing to track if you're just going on a short tangent, just commit your stuff, and go back to the original to merge if it was a good idea or forget if it was not. And yes you can create a bookmark "after the fact" e.g. do half a dozen commits, realise that it's going to take longer than you thought and create a bookmark for the current experiment on the tip.

Re: Prefer mercurial to git

#46

Post by blibble »

rmetzler wrote: post #27
hawkharris wrote: post #5

Earlier 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

http://mercurial.selenic.com/wiki/GpgExtension

Re: Prefer mercurial to git

#49

Post by falicon »

spellboots wrote: post #3

I 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…

Most people prefer what they already know (learning any new system or process is always frustrating because you are attempting to map concept rather than learn concepts - square peg, round hole).

I prefer (and use) git myself, but it took awhile (and much of my developer/friend network to go first) for me to commit to the switch from subversion...my main issue was that subversion worked well enough for what I needed/wanted at the time. I didn't really switch until it became harder to work with others because of my subversion use and easier to work with others if/when I adopted git.

Re: Prefer mercurial to git

#50

Post by Luyt »

gcv wrote: post #23
[deleted] wrote: post #9

Earlier quoted context omitted.

[deleted]

No, the project's leads have already approved the move to Git, and ESR is spearheading the (massive) effort involved.

Indeed, ESR wrote this about it: http://esr.ibiblio.org/?p=5211

"This is a brief heads-up that the reason I’ve been blog silent lately is that I’m concentrating hard on a sprint with what I consider a large payoff: getting the Emacs project fully converted to git. In retrospect, choosing Bazaar as DVCS was a mistake that has presented unnecessary friction costs to a lot of contributors. RMS gets this and we’re moving.

I’m also talking with RMS about the possibility that it’s time to shoot Texinfo through the head and go with a more modern, Web-friendly master format. Oh, and time to abolish info entirely in favor of HTML. He’s not entirely convinced yet of this, but he’s listening."

He's also involved in freeing code-repositories from their prisons, and porting them to other versioning systems, with the Reposurgeon. See https://gitorious.org/reposurgeon/

"reposurgeon enables risky operations that version-control systems don’t want to let you do, such as (1) editing past comments and metadata, (2) excising commits, (3) coalescing commits, and (4) removing files and subtrees from repo history. The original motivation for reposurgeon was to clean up artifacts created by repository conversions. It also functions as a repository conversion tool. Supported VCSes include git, hg, bzr, and Subversion."

Post reply on HN