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

81–90 of 189 posts

Re: Prefer mercurial to git

#81

Post by masklinn »

ufmace wrote: post #77
masklinn wrote: post #45

Earlier quoted context omitted.

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

I hadn't heard of that, and it does sound like a nice feature, but it still seems a little hacky compared to Git branches. At best, it would be as good as them, but then why not stick with the original? Oddly enough, I find myself liking the simplicity of Git here. You can do pretty complex stuff with it, but having only one type of branch seems to help some. That, and the local-only stashsets, which seem to be inten…

> I hadn't heard of that, and it does sound like a nice feature, but it still seems a little hacky compared to Git branches.

It's exactly the same thing git branches do. If it seems hacky, it's also hacky in git.

> At best, it would be as good as them, but then why not stick with the original?

Stick with what original? The originals in mercurial are branches (where the branch name is part of the commit metadata and thus of the repository's history forever, save for history rewriting) and "anonymous heads".

Then users clamoured for transient (movable, renamable, deletable) git-style branches, so bookmarks were added as an option.

> cloned repos

Erm… you can also clone repositories in git.

> I'm not really sure how they all interact

At the end of the day, it's all commit DAG.

Re: Prefer mercurial to git

#82

Post by sixthloginorso »

Why are people sweating small stuff like version control systems? How can you be a fanboy of a thing that keeps track of branches and patches. It's only incidentally related to Software development, you shouldn't feel as if a limb of yours was amputated if you \gasp\ had to use a different one for another project.

It's like using a different mail client or a different bug tracker; it doesn't affect what you can express or how can you build a program. It's just Version Control.

Re: Prefer mercurial to git

#83

Post by perfunctory »

Mine might be a very unpopular opinion, but I couldn't care less about different kinds of (D)VCS. I've got a feeling that recently I, and other team members, spend more and more time on branching, rebasing, cloning, merging etc. and less time on actual code writing.

Re: Prefer mercurial to git

#84

Post by michael_storm »

masklinn wrote: post #73
michael_storm wrote: post #69

Earlier quoted context omitted.

> There, I fixed it. GP's point was about defaults, not what you can configure. Even being somewhat familiar with hg, I didn't know about the "pager" extension. > `git show` does not show a patch by default[...] It does for me, with git 1.7.9.5. > (hg has no prohibition against what git calls "detached heads", they're just anonymous branches) I have never understood why this is useful. Why not just name your heads so…

> GP's point was about defaults Granted, but he then describes the difficulty of typing `hg log | less`. And defaults cut both ways, I still can't fathom why `git log HEAD` would display the whole repository history. > It does for me, with git 1.7.9.5. Doesn't for me with git 1.8.5.4. Regardless I removed that part since it's not the gist of the issue and the official documentation asserts it should. > I have never u…

> And defaults cut both ways, I still can't fathom why `git log HEAD` would display the whole repository history.

I don't know why that's part of the defaults discussion, but okay.

> Why is a meaningless name better than no name at all? Why is git's default behaviour of losing unnamed heads altogether better than just leaving them alone?

Why would you give a meaningless name? That's a red herring. Do hg users just memorize which head is which?

Mercurial users seem to get hung up on detached heads a lot. They seem to be part of the Mercurial workflow in a way that I've never really understood. But git's detached heads are at least created when I expect them to be, are easily deleted, and are easily saved.

Mercurial's detached heads (or whatever they're called) want me to either merge them (why would I merge commits that popped up out of nowhere?), or close them as described in http://stackoverflow.com/questions/3688263/mercurial-beheadi... (apparently causing these mysterious heads to be saved forever). I much prefer a DAG with labels, instead of all this state specific to Mercurial that I have to manage.

Re: Prefer mercurial to git

#85

Post by levesque »

perfunctory wrote: post #83

Mine might be a very unpopular opinion, but I couldn't care less about different kinds of (D)VCS. I've got a feeling that recently I, and other team members, spend more and more time on branching, rebasing, cloning, merging etc. and less time on actual code writing.

Given that you "spend more and more time on branching, rebasing, cloning, merging, etc. and less time on actual code writing", shouldn't you care more about the different kinds of VCS?

Seems having the right tool should be important.

Re: Prefer mercurial to git

#86

Post by DannyBee »

masklinn wrote: post #42
Hello71 wrote: post #28

Earlier quoted context omitted.

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

actually, it's possible to execute clone in git without it checking. If you do a local clone, it will happily hand you a broken repo.

Re: Prefer mercurial to git

#87

Post by haberman »

Perseids wrote: post #31
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.)

In git a commit is basically the root of a Merkle Tree [1], i.e. every reference is the sha1 sum of the object being referenced. If you take a commit apart what you see is a commit message, a hash of its parent commit and a hash of a tree object. That tree object itself contains hashes of file objects and tree object as well as their corresponding names. Thus assuming you would want to tamper with a file of a commit…

> So the complete state of the repository is cryptographically secured

It should be noted, however, that Linus and others specifically disclaim that this is a security mechanism:

"Git uses SHA-1 in a way which has nothing at all to do with security.... It's just the best hash you can get.... It's about the ability to trust your data." --Linus (http://en.wikipedia.org/wiki/SHA-1#Data_integrity)

And in the midst of a discussion about how only professional cryptographers should design crypto, pretty much everyone insists that Git is not crypto (see replies to: https://news.ycombinator.com/item?id=6961683)

Re: Prefer mercurial to git

#88

Post by twic »

blibble wrote: post #53
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…

git is as prone to bitrot as hg. git doesn't run fsck on the entire repo for each operation, and unless you fsck or clone you won't detect corruption for quite a while. it's exactly the same for hg, which is built on the same hashing concept as git (actually the other way round, as hg came first).

Moreover, Mercurial's storage scheme is built on append-only files, whereas Git periodically repacks its objects, which means that Mercurial actually has fewer opportunities for cosmic rays to hit the bits while they are in motion, and so less chance of corruption.

Re: Prefer mercurial to git

#89

Post by _delirium »

wes-exp wrote: post #55
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.

Quite frankly, not sharing GNU's goals is a feature, not a bug. The less the source code is encumbered by onerous political restrictions, the better.

Quite frankly, not sharing GNU's goals is a bug, not a feature. The less the source code is encumbered by onerous political restrictions, the better.

Re: Prefer mercurial to git

#90

Post by cliffbean »

hawkharris wrote: post #5
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…

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

It's worth noting that Git's hashes guard against accidental corruption; they aren't widely thought to be strong against attack by an intelligent adversary.
Post reply on HN