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

171–180 of 189 posts

Re: Prefer mercurial to git

#171

Post by Perseids »

cdoxsey wrote: post #167
Perseids wrote: post #133

Earlier quoted context omitted.

To be honest I don't buy his argument. If it is not about security, why not use md5? It is faster after all and gives you the same protection against accidental data corruption as sha1. And if he cared about security then he should have chosen sha256 or sha512, the latter of which is even faster than sha1 on 64bit systems [1] and can be truncated if you think it is too long. And really there is no denying that git re…

Intel is adding native SHA instructions to x86... so sha1 will probably be much faster on those CPUs. http://en.wikipedia.org/wiki/Intel_SHA_extensions

Interesting…

Note that they also add sha256 specific instructions. Which is good, because sha1 should no longer be used for new application and existing application should definitely start looking into an update path. See [1] for a rough estimate how fast the existing (publicly known) attacks become feasible.

I hope they are also working on implementing the sha3 permutation. That would allow for some really cool features to be super fast and simple like authenticated encryption or reseedable pseudo random number generation[2].

[1] https://www.schneier.com/blog/archives/2012/10/when_will_we_... [2] For details see section 5 and 6 of https://eprint.iacr.org/2011/499.pdf

Re: Prefer mercurial to git

#172

Post by ufmace »

masklinn wrote: post #81
ufmace wrote: post #77

Earlier quoted context omitted.

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

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

I more meant that it seems hacky to add a feature that's mostly-sorta like Git branches to Mercurial now.

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

I meant original as in Git vs Mercurial. Like if you want Git-like branches, then why not just stick with Git?

> Erm… you can also clone repositories in git.

Yeah, you could, but I've never seen anybody recommend cloning a Git repo on the same computer for the purpose of separating out work from the main branch. At least for a while, this seemed to be widely recommended way of separating code out in Mercurial.

Where things get kinda weird - in Git, if you want to commit code somewhere that doesn't go into main just yet, there are only 2 options - branches and stash, and stash is explicitly meant to be a very short-term, local thing, since you can't really share them easily and they aren't really part of the commit hierarchy. That makes things simpler, as you never have to wonder what the right feature to use is for keeping separate work somewhere and sharing it with other people. You can create complex structures with branches, but at least there's only one 'type' of thing to keep track of.

I'm not as familiar with Mercurial, but for ways to keep temporary work somewhere, it seems we have named branches, anonymous branches, bookmarks, cloned repos on the same system, and apparently shelve too. According to this guy[1], the workflows for sharing bookmarks around don't seem to be fleshed out all that well either. So how do I know which one to use for what tasks?

[1] http://www.kevinberridge.com/2012/05/hg-bookmarks-made-me-sa...

Re: Prefer mercurial to git

#173

Post by alinajaf »

haberman wrote: post #144
Perseids wrote: post #133

Earlier quoted context omitted.

To be honest I don't buy his argument. If it is not about security, why not use md5? It is faster after all and gives you the same protection against accidental data corruption as sha1. And if he cared about security then he should have chosen sha256 or sha512, the latter of which is even faster than sha1 on 64bit systems [1] and can be truncated if you think it is too long. And really there is no denying that git re…

I am not sure I buy it either. To me it comes off as cognitive dissonance between the party line of "don't invent your own crypto" and the pervasive love and acceptance of Git. No one wants to say that Git, on which many of our SCM processes are now built, is suspect. But also no one wants to argue that Linus is somehow an exception to the rule against amateur cryptography. So what we're left with a somewhat ambiguou…

> Git is described as not being crypto

Git has plenty of crypto in it, namely GPG (for signing tags), SSH and SSL (for transport). Using off-the-shelf crypto like this doesn't strike me as "inventing your own crypto".

> people assume it is resistant to malicious attack

Exactly what's the threat model here? I can't conceive of a malicious attack that exploits gits reliance of on SHA1 as a message digest that doesn't also require write access to your filesystem.

I think your argument stems from the fact that SHA1 is deemed insecure and therefore anything associated with it must also be insecure. As I said in the previous thread, git doesn't use SHA1 to make any of the guarantees that cryptography is typically used to make.

It's usage is to prevent accidental corruption in the everyday usage of git (the sort that mercurial appears to have been prone to in the past), not to protect against a malicious adversary with write access to the filesystem.

Re: Prefer mercurial to git

#174

Post by harel »

ygra wrote: post #135
harel wrote: post #95

Earlier quoted context omitted.

That's true, in a way, until someone tries to force CVS on you. Yes they are all sideline tools but once you get used to something, its the best thing in the world, until you get used to something else. Change is great, but not quite appreciated enough.

At work (where my script to convert all of our projects from CVS to Hg is complete for almost ¾ of a year now) I now resort to a hacky PowerShell script that allows me to work locally with Hg and then push selected revisions to CVS. Mostly because I fear that we won't ditch CVS for quite a while and when we do I'm probably the one to blame for lost developer productivity while we're coming to grips with a new tool.

So many wrongs in one comment. The fact you believe you'll be blamed for dev productivity loss is just not right. Blame? The fact you have to write scripts converting from one source control to another is not good, the fact you resort to hacky powershelling is scary. I wasn't even thinking the "are they still using cvs in 2014" even but I guess I should have. "blame" should exist in source control systems only.

Re: Prefer mercurial to git

#175

Post by haberman »

alinajaf wrote: post #173
haberman wrote: post #144

Earlier quoted context omitted.

I am not sure I buy it either. To me it comes off as cognitive dissonance between the party line of "don't invent your own crypto" and the pervasive love and acceptance of Git. No one wants to say that Git, on which many of our SCM processes are now built, is suspect. But also no one wants to argue that Linus is somehow an exception to the rule against amateur cryptography. So what we're left with a somewhat ambiguou…

> Git is described as not being crypto Git has plenty of crypto in it, namely GPG (for signing tags), SSH and SSL (for transport). Using off-the-shelf crypto like this doesn't strike me as "inventing your own crypto". > people assume it is resistant to malicious attack Exactly what's the threat model here? I can't conceive of a malicious attack that exploits gits reliance of on SHA1 as a message digest that doesn't a…

> It's usage is to prevent accidental corruption in the everyday usage of git (the sort that mercurial appears to have been prone to in the past), not to protect against a malicious adversary with write access to the filesystem.

I have evidence that people in practice use it to protect against just this sort of thing: https://news.ycombinator.com/item?id=7003900

Re: Prefer mercurial to git

#176

Post by Karunamon »

glogla wrote: post #159
belorn wrote: post #147

Earlier quoted context omitted.

What you said was: > BSD is a de-facto more permissive license. ... And people who want to use my code don't have to get involved in GPL politics and drama! So yes, you statement was an "BSD as the right choice, GPL is the wrong choice". If you actually want to be tolerant of people right to license what they want, you should not badmouth their choices when they don't pick the same as you. > as long as the KKK releas…

I wonder why is it always the anti-GNU people who are behaving like raging teenagers? I have never heard FSF advocate call people zealot or "fucking idiotic" for preferring other license, but the other way around it's a rather common occurrence. I don't want to generalize, but I guess it has to do with they kinds of people who like and dislike GNU. The day when people will say "oh I like BSD better" instead of "OMG B…

Who'd have thought? Some people don't like being called "evil" for what they choose to do with their code.

Re: Prefer mercurial to git

#177

Post by jebblue »

bjourne wrote: post #123
jebblue wrote: post #98

Earlier quoted context omitted.

Well I Googl'ed: gnu fsf "you're either with us or against us" And it turns out that the idea shows up more than once. So it must be at least believed by some to be true. That includes this interesting post on Slashdot from 2001: http://interviews.slashdot.org/story/01/12/13/0242205/miguel... In particular, a comment by ukryule seems especially applicable: "Taken in the spirit intended. I accept that the GNU principl…

This must be the most intellectually dishonest comment I've read in a while. Either find someone from FSF who's written what you're claiming or this discussion is over. Finding unrelated people who feels something about the FSF's position and quoting that .. is just silly.

You must be confused. I'm not claiming anything at all. I'm saying Google something and I'm saying someone wrote something 13 years ago. Any conclusions you draw are your own.

Re: Prefer mercurial to git

#178

Post by alwillis »

exDM69 wrote: post #153
dhimes wrote: post #61

Earlier quoted context omitted.

This is it exactly. A lot of people miss this with hg. hg bookmarks are the equivalency to git branches. hg branches are "permanent." So you have, say, 'dev,' 'test' and 'stable' branches. Then you do hot-fixes and feature development on bookmarks, and merge them back into the branches. It's a beautiful thing, really

> hg bookmarks are the equivalency to git branches. In my opinion, this is not all good although it clearly solves a problem. Having two somewhat non-orthogonal features for branching undoes a part of the easier learning curve argument. You end up having to educate people whether to use bookmarks or branches and in what situations. If branches are permanent, who are allowed to create branches? Everyone or just mainta…

>Having two somewhat non-orthogonal features for branching undoes a part of the easier learning curve argument. You end up having to educate people whether to use bookmarks or branches and in what situations.

Like most things, it depends. But mostly no, it doesn't impact the learning curve issue, especially if your team uses the git branching model, you never even have to address Mercurials named branches.

I'd also say all the other advantages of Mercurial far out-weigh something a conceptually simple as "use bookmarks for git-like, non-permanent branches; use named branches for permanent branches." Done.

Re: Prefer mercurial to git

#179

Post by alwillis »

exDM69 wrote: post #153
dhimes wrote: post #61

Earlier quoted context omitted.

This is it exactly. A lot of people miss this with hg. hg bookmarks are the equivalency to git branches. hg branches are "permanent." So you have, say, 'dev,' 'test' and 'stable' branches. Then you do hot-fixes and feature development on bookmarks, and merge them back into the branches. It's a beautiful thing, really

> hg bookmarks are the equivalency to git branches. In my opinion, this is not all good although it clearly solves a problem. Having two somewhat non-orthogonal features for branching undoes a part of the easier learning curve argument. You end up having to educate people whether to use bookmarks or branches and in what situations. If branches are permanent, who are allowed to create branches? Everyone or just mainta…

This article is a little dated, but it conveys the flexibility of Mercurial branching.[1]

I don't know why git users get so hung up on named branches—you never have to use them if they don't make sense for your project.

[1] http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...

Re: Prefer mercurial to git

#180

Post by ygra »

harel wrote: post #174
ygra wrote: post #135

Earlier quoted context omitted.

At work (where my script to convert all of our projects from CVS to Hg is complete for almost ¾ of a year now) I now resort to a hacky PowerShell script that allows me to work locally with Hg and then push selected revisions to CVS. Mostly because I fear that we won't ditch CVS for quite a while and when we do I'm probably the one to blame for lost developer productivity while we're coming to grips with a new tool.

So many wrongs in one comment. The fact you believe you'll be blamed for dev productivity loss is just not right. Blame? The fact you have to write scripts converting from one source control to another is not good, the fact you resort to hacky powershelling is scary. I wasn't even thinking the "are they still using cvs in 2014" even but I guess I should have. "blame" should exist in source control systems only.

Actually I was agreeing to your point that at the time when CVS is used version control is no longer "just a tool" but a PITA.

I'm the one who suggested conversion to a newer system, so when the other developers need to re-learn and lose a week of productivity that way it is my fault, to some extent.

My conversion script is essentially just automating creating cvs2hg config files for a number of CVS modules (and cleaning up before/after conversion) because our CVS repo is a few GiB in size, containing everything that ever existed (and plenty of things beside that) so a 1:1 conversion isn't that ideal, especially because it will lead to frequent (harmless) merges. But to developers with a CVS background merges are scary.

My cvshg PowerShell script is based around https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS and http://pavelchikulaev.wordpress.com/2012/04/09/using-mercuri..., but tailored to how I use the tools. It allows me to commit happily locally and histedit later when I need commits I can actually share with others.

Post reply on HN