LWN.net Logo

Hg Init: a Mercurial tutorial

Hg Init: a Mercurial tutorial

Posted Feb 24, 2010 17:49 UTC (Wed) by bjacob (subscriber, #58566)
In reply to: Hg Init: a Mercurial tutorial by realnc
Parent article: Hg Init: a Mercurial tutorial

Two things:

1) git allows anyone with write access to damage your history with 'git push -f'. While this is OK for a very-decentralized project like Linux, it doesn't work well for projects that have a central repository with hundreds of writers.

2) git (the official git client) still isn't a native application on Windows.

I too was believing that git was the only serious scm, until I learnt that Mozilla, Python and OpenOffice were using Hg --- and the reasons for that.


(Log in to post comments)

Hg Init: a Mercurial tutorial

Posted Feb 24, 2010 19:12 UTC (Wed) by juliank (subscriber, #45896) [Link]

> git allows anyone with write access to damage your history with
> 'git push -f'.

How about 'hg push -f' or 'bzr push --overwrite'? All distributed SCMs I use
allow this.

Hg Init: a Mercurial tutorial

Posted Feb 24, 2010 19:45 UTC (Wed) by bjacob (subscriber, #58566) [Link]

Except that 'hg push -f' has nothing to do with 'git push -f'.

Doing 'hg push -f' will, at worst, create a new head alongside the existing ones.

With Hg, the history is an immutable collection that can only grow; existing history is set in stone and can't be altered. You can only append to it.

Hg Init: a Mercurial tutorial

Posted Feb 25, 2010 14:06 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

History is most certainly mutable in Hg. Even without considering the mq extension, 'rollback' will remove the last changeset.

Hg Init: a Mercurial tutorial

Posted Feb 28, 2010 16:13 UTC (Sun) by bjacob (subscriber, #58566) [Link]

About rollback: OK but its effect is very limited: it affects only the last transaction.
About queues: it's a special enough case that their mutability doesn't mean that hg history as a whole is mutable...

Hg Init: a Mercurial tutorial

Posted Feb 28, 2010 16:14 UTC (Sun) by bjacob (subscriber, #58566) [Link]

For the record, I have just learnt that gitorious.org offers an option to disable "git push -f" altogether.

Hg Init: a Mercurial tutorial

Posted Feb 24, 2010 22:45 UTC (Wed) by nix (subscriber, #2304) [Link]

1) it's pretty easy to reverse such 'damage' (rewind the affected branches
and prune).

2) git has been a native application on Windows for years now.

Hg Init: a Mercurial tutorial

Posted Feb 25, 2010 0:59 UTC (Thu) by bjacob (subscriber, #58566) [Link]

"2) git has been a native application on Windows for years now."

Then the wikipedia must be wrong:
http://en.wikipedia.org/wiki/Git_%28software%29#Portability

Hg Init: a Mercurial tutorial

Posted Feb 25, 2010 1:42 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

it looks like wikipedia has been fixed now.

Hg Init: a Mercurial tutorial

Posted Feb 25, 2010 4:02 UTC (Thu) by dkrawchuk (subscriber, #21896) [Link]

I use git daily in Windows to manage Unigraphics part files which are large binary files and it works well and is easy enough to use. A half a dozen commands to learn and you are away. http://www.kernel.org/pub/software/scm/git/docs/everyday.... is enough to get the average person going. I tried hg but it does not handle binary files well.

Hg Init: a Mercurial tutorial

Posted Feb 25, 2010 8:55 UTC (Thu) by bboissin (subscriber, #29506) [Link]

In what way does it not handle binary files well, in theory there aren't
many differences in the way they deal with them.

Hg Init: a Mercurial tutorial

Posted Feb 26, 2010 0:46 UTC (Fri) by cortana (subscriber, #24596) [Link]

It handles binary files just fine. It handles *large* files (text or binary) poorly though. Specifically I am referring to the Windows port (msysgit) which tries to compress files before sending them to the server; if it runs out of memory (which it will, since it's only a 32-bit application and so can only address a couple of GiB of RAM) then it dies with a typically obtuse error message.

Hg Init: a Mercurial tutorial

Posted Feb 26, 2010 6:43 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

git also has issues with large files.

the point at which a file gets large enough to cause problems (and what the problems are) are obviously different between the two.

Hg Init: a Mercurial tutorial

Posted Feb 26, 2010 9:43 UTC (Fri) by cortana (subscriber, #24596) [Link]

Whoops! To clarify, I was referring to Git rather than "it" (hg) :)

Hg Init: a Mercurial tutorial

Posted Mar 4, 2010 10:42 UTC (Thu) by jmansion (guest, #36515) [Link]

> 2) git has been a native application on Windows for years now.

There's a difference between 'runs on Windows' and 'is usable on Windows'.

Does it have support for understanding that its more convenient for text files on Windows to have CRLF endings, and that it should hide this when editing cross-platform files on Windows and posix platforms?

hg seems nice to me. I was enjoying bzr too but hgEclipse is sufficiently better than bzrEclipse that I'm transitioning to hg.

To be honest, having upstream devs who care about the cross-platform stuff is enough to make hg a clear win for me compared to having a secondary port for Windows. It doesn't really matter to me if git is better than hg on linux.

Hg Init: a Mercurial tutorial

Posted Mar 4, 2010 15:20 UTC (Thu) by nye (guest, #51576) [Link]

>Does it have support for understanding that its more convenient for text files on Windows to have CRLF endings, and that it should hide this when editing cross-platform files on Windows and posix platforms?

Yes.
Set autocrlf appropriately (I *believe* it's enabled by default on Windows). It even has the 'input' setting which will convert CRLF to LF when committing but not when checking out, which can be very useful if you ever copy files from one system to another, and I always enable on Linux.

Git has the expected heuristics to decide whether a file is binary or text, along with the ability to add a hint if you need to.

It's also capable of detecting a mixture of line endings and can be configured to convert them all one way or the other if you want it to (see the safecrlf option).

(Although I have to say that it's been *years* since I came across a single Windows application that choked on LF-only line endings, and whose name isn't 'notepad.exe'.)

>To be honest, having upstream devs who care about the cross-platform stuff

Git seems to have more attention paid to the CRLF problem than the other VCSes I've used in the past, though I've never used Mercurial. Not to mention that portability is a big deal for Git which goes to great lengths to work on a wide variety of platforms.

Hg Init: a Mercurial tutorial

Posted Feb 25, 2010 0:50 UTC (Thu) by cmccabe (guest, #60281) [Link]

I've used git in a corporate environment before. It works fine. People just need to be trained in how to use it.

The major downside is that the msysgit client for Windows is kind of slow. Although I don't use Windows personally, if other people in the organization do, this could be an issue.

> 1) git allows anyone with write access to damage your history with
> 'git push -f'. While this is OK for a very-decentralized project
> like Linux, it doesn't work well for projects that have a central
> repository with hundreds of writers.

Everyone will notice pretty quickly if the history gets messed up. Then you can restore from a backup, chastise the guilty developer, and go about your merry way. Luckily, with git, every developer in the company can act as your backup.

Hg Init: a Mercurial tutorial

Posted Feb 25, 2010 16:05 UTC (Thu) by djpig (subscriber, #18768) [Link]

> 1) git allows anyone with write access to damage your history with
> 'git push -f'. While this is OK for a very-decentralized project like
> Linux, it doesn't work well for projects that have a central
> repository with hundreds of writers.

That's what receive.denyNonFastForwards is for.
Of course for any reasonable complex setup you probably want to write an update hook anyway.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds