LWN: Comments on "Hg Init: a Mercurial tutorial"

Hg Init: a Mercurial tutorial

nye — Thu, 04 Mar 2010 15:20:05 +0000

>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

jmansion — Thu, 04 Mar 2010 10:42:55 +0000

> 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

oblio — Wed, 03 Mar 2010 21:45:07 +0000

You can change the colors of course, to suit your idea of "right side changed" or "left side changed". Secondly, I don't care much about the "eye movement", since you can use "Next change"/"Previous change" buttons which move everything for me.

At this point, it boils down to: "I'm wired like this" or "I'm used like this". So any debate is moot. It's like religious people versus atheists. Nobody's right, since there is no "right" :)

Hg Init: a Mercurial tutorial

nix — Wed, 03 Mar 2010 12:55:17 +0000

Sorry, I found that graphical output horrible. The colours don't
signify 'appeared' or 'disappeared' in any particular fashion, lots of the
code is duplicated on both sides, spontaneously inserted vertical space
that doesn't exist in *any* version of the actual code, massive eye
movement is needed to figure out what changed... ew. Give me a unified
diff anyday. (Context diffs have the same problem as the graphical output:
massive eye movement just to figure out if a line was added or not.)

Hg Init: a Mercurial tutorial

oblio — Tue, 02 Mar 2010 18:09:37 +0000

> I wasn't intending to argue. I know what you say is true, but it baffles me. I really would like to understand the reasons behind the difference - I do use predominantly GUI applications, but this is one of many examples where I find the GUI massively harder to use.

Well... for all sorts of analysis something graphical is easier to use. At least for regular people like me :)

It's much easier to spot the differences when comparing text for example, if the diff program uses different background colors and foreground colors, tooltips and other various visual hints to help see changes.
Compare this output:
$ svn diff
Index: bar.c
===================================================================
--- bar.c (revision 3)
+++ bar.c (working copy)
@@ -1,7 +1,12 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+
+#include <stdio.h>

int main(void) {
- printf("Sixty-four slices of American Cheese...\n");

To this one:
http://winmerge.org/about/screenshots/screenshot.png

svn diff is good as a part of an API, but not as an user interface, that's for sure :)

Secondly - some changes just are visual. I'm a Vim user and I still don't use the multipliers for moving around text for example. My brain just isn't wired to move 5w, it's wired to go the end of the line for example (which is more of a visual cue).

For example, when merging, a GUI makes things a little bit easier - click a portion of the code, "Use this section". I'm reusing things I know (like pointing :) ), and the interface guides me (and maybe even protects me, since copy/paste or manual editing of the line are error prone).

> I don't really see why anyone cares, TBH :P

Because most people have day jobs? Of course companies and their projects are a big deal :)

Hg Init: a Mercurial tutorial

nye — Tue, 02 Mar 2010 11:37:22 +0000

>Good for you. For most developers out there (and for most people), GUIs have surpassed CLIs for a long time. This is not the place to argue the merits of each.

I wasn't intending to argue. I know what you say is true, but it baffles me. I really would like to understand the reasons behind the difference - I do use predominantly GUI applications, but this is one of many examples where I find the GUI massively harder to use.

>I'm just pointing out that without a great GUI client, widespread usage, especially in companies, won't happen. And not all the world's projects are community projects ;)

I don't really see why anyone cares, TBH :P

mq seems very limited

intgr — Tue, 02 Mar 2010 10:34:29 +0000

> I cannot do the basic stuff, such as posting series of patches
You mean the patchbomb extension? Seriously, did you even try Google?

Hg Init: a Mercurial tutorial

sitaram — Tue, 02 Mar 2010 08:55:32 +0000

looks nice... I'm sure someone will convert it to git (assuming the copyright allows); the first chapter (for SVN folks), is very impressive.

git "too hard to use"?

cmccabe — Sun, 28 Feb 2010 20:25:35 +0000

> I am sorry, but that it is nonsense. It is impossible to merge binary files
> like .DOC, .PDF, artwork, etc. Those ate precisely the type of documents
> that non-developers need. Branches are actively harmful to them.

It's impossible to merge them *automatically*. This is a flaw in the file format and toolset, and has nothing to do with version control per se.

If you have more than one documentation writer on the payroll, you're already spending time merging changes manually. Even if you make each chapter (or whatever) of documentation a separate file, there will still be some cross-references and dependencies.

If you would have used .tex and .svg, you wouldn't have this problem, or at least not to this extent. If you like Microsoft, their Sharepoint stuff is designed to solve exactly this problem-- to make office documents mergeable.

It's hard to see how you can get away from using subversion and mandatory locking with the workflow you have now. But this is not because employees are too stupid to understand branching. It's because the tools you are using are old and rusty, and don't support the diff operation. This also will make it hard for you to audit what people have done. If I make a few spelling corrections to the PDF and then commit it as "added whole new section on zebras" how is my manager going to know the difference? You're just using the honor system, basically.

By the way, if you need mandatory locking and good handling of binary files, you might also check out Perforce. They have good GUI and Windows support (although subversion has been improving a lot lately.)

Hg Init: a Mercurial tutorial

bjacob — Sun, 28 Feb 2010 16:14:59 +0000

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

Hg Init: a Mercurial tutorial

bjacob — Sun, 28 Feb 2010 16:13:43 +0000

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

VCS with locks

nix — Sat, 27 Feb 2010 22:03:05 +0000

It helped that other branches of the same organization (for 'other
branches' read 'sitting across the room') had been convinced by these
auditors, so were using SCCS with a horrible shell script wrapper to
attempt to provide some semblance of branching, and auditor-imposed
constraints to prevent reservation in a wide variety of situations (such
as a single client out of hundreds querying something in *any* previous
change touching the same file: want to make an unrelated change touching
such a file, got to find a way to make it in a different file instead!),
so everyone talking to the auditors knew *exactly* how horrible their
proposed golden age would be.

VCS with locks

man_ls — Sat, 27 Feb 2010 21:17:11 +0000

You were quite brave to convince the auditors. In a way it is easy since git provides many more auditing features, but the process does not look so rosy.

But I have also to say that you were lucky: I have worked at places where the developers themselves could not be convinced to work without locks, and distributed VCS was alien technology. It was trebly painful: they did not trust nor understand lock-free VCS, they should have known better, and up to now they are still working with locks (with all that it entails).

VCS with locks

nix — Sat, 27 Feb 2010 18:46:32 +0000

I've worked at places where auditors who believed this came in, and tried
to force everyone to go back from git to (I kid you not) SCCS.

Convincing them otherwise was most unpleasant. I wish we could just have
lied to them to get them to go away.

VCS with locks

man_ls — Sat, 27 Feb 2010 17:53:52 +0000

Sorry, the first should be those who still want to work with locks (à la SourceSafe): lock/checkout/checkin/unlock. There are many, and they believe that working without locks is "unsafe". In comparison svn advocates are patron saints of the arts.

git "too hard to use"?

man_ls — Sat, 27 Feb 2010 15:05:50 +0000

From experience, the lock-modify-unlock model and Visual Source Safe specifically, is the best VCS for non-developers.

Also from experience, the lock-modify-lock is still the right way to do things for some developers (and I am saying this with shame). A bit ironically, working without locks is easier with distributed systems such as hg than with centralized systems such as SVN.

git "too hard to use"?

mikov — Sat, 27 Feb 2010 00:23:50 +0000

> Yes they do. Since when do documentation writers not need to manage
> revisions to their documentation?

They don't want to create and manage branches. They want to work on
branches others have created. However in Git creating a branch is often
implicit or required in ordinary work-flow, which makes it confusing for
people.

> What are they doing using rebase? You should never use that on a branch
> that has been published for others to see.

This is not the place and time to explain how Git works, but in short, if
you don't want to create an implicit branch when pulling, you have to do a
"git-pull --rebase". Rebasing is an essential activity when maintaining
your local repository, but it can also be confusing to non-technical
people.

> Thats not how the real world works. Even with common-or-garden office
> documents, its common for them to be passed around to different people
> who will make comments and submit annotations, all of which have to be
> collated and reconciled together somehow. A distributed VCS merely
> formalizes the process. The more complex the documentation, the more
> important such formalization becomes.

I am sorry, but that it is nonsense. It is impossible to merge binary files
like .DOC, .PDF, artwork, etc. Those ate precisely the type of documents
that non-developers need. Branches are actively harmful to them.

> Concepts of branches, tagging and merging are common to all modern
> version control systemstheres nothing specific to Git about any of
> them. Whats different about Git is the fact that your entire commit
> history is nothing but a DAG, and branches and tags are just pointers
> into that DAG.

I am not interested in Git advocacy. As I mentioned earlier, I find Git
excellent for development (perhaps the best VCS there is), but too complex
for non-developers (and actually for many developers too). The latter is an
observable fact, not just an opinion. The reluctance to accept it is a bit
perplexing to me.

git "too hard to use"?

ldo — Fri, 26 Feb 2010 23:29:55 +0000

mikov wrote:

The people I am referring to are not 'software developers'. I mentioned documentation writers, testers, web designers, etc. They don't need and don't want to manage branches.

Yes they do. Since when do documentation writers not need to manage revisions to their documentation?

Yet, every git-pull is potentially a merge and git-rebase requires understanding of what commits are, the relation between hashes and commits, etc.

What are they doing using rebase? You should never use that on a branch that has been published for others to see.

From experience, the lock-modify-unlock model and Visual Source Safe specifically, is the best VCS for non-developers. They really really like that by default a file can be checked out and modified only by a single person.

Thats not how the real world works. Even with common-or-garden office documents, its common for them to be passed around to different people who will make comments and submit annotations, all of which have to be collated and reconciled together somehow. A distributed VCS merely formalizes the process. The more complex the documentation, the more important such formalization becomes.

Concepts of branches, tagging and merging are common to all modern version control systemstheres nothing specific to Git about any of them. Whats different about Git is the fact that your entire commit history is nothing but a DAG, and branches and tags are just pointers into that DAG.

repository format?

bfields — Fri, 26 Feb 2010 21:42:22 +0000

If you use packs (as everybody does), corrupted writes in the pack could destroy the history too (but they probably use transactions and checks like hg to detect it).

No, my understanding is that packs are write-once just like other objects. (So you have to pack loose objects every now and then to keep performance from degrading.)

mq seems very limited

proski — Fri, 26 Feb 2010 21:14:50 +0000

As a heavy STGig user, the Mercurial mq extension seems very underpowered. I cannot do the basic stuff, such as posting series of patches. If I want to hack on a project that uses Mercurial, I import it into a git repository and work on it with STGit. Unfortunately, I'm not aware of any tool like git-svn that would allow me to track a Mercurial repository with git.

git "too hard to use"?

mikov — Fri, 26 Feb 2010 20:11:40 +0000

Wrong and wrong again.

This is a good example of the kind of naivete that doesn't actually help
people use Git in the real world

The people I am referring to are not 'software developers'. I mentioned
documentation writers, testers, web designers, etc. They don't need and
_don't want_ to manage branches. Yet, every git-pull is potentially a merge
and git-rebase requires understanding of what commits are, the relation
between hashes and commits, etc.

Take the following example error message, which while technically very
meaningful, would be utterly confusing to them:

"error: failed to push some refs to '....'
To prevent you from losing history, non-fast-forward updates were rejected"

Refs? non-fast-forward? WTF?

Whether they have been 'damaged' by using 'inferior VCS' is
questionable, but regardless, they are what they are, and they may be fully
competent at their respective jobs without understanding Git or knowing
what a SHA hash is.

From experience, the lock-modify-unlock model and Visual Source Safe
specifically, is the best VCS for non-developers. They really really like
that by default a file can be checked out and modified only by a single
person.

I am thinking that the right solution to this kind of problem may be to
develop reverse bridges. A bridge from Git to SVN, or from Git to VSS. So
that the main repository can be kept in Git, but parts of the team can
interact with it through the safe environment of "lock-modify-unlock".

git "too hard to use"?

cmccabe — Fri, 26 Feb 2010 19:06:16 +0000

No, no, and no.

This is a good example of the kind of brain damage that years of using an inferior version control system can inflict on people.

Merging and branching aren't complicated and arcane operations that only special experts can handle. They're routine operations that every software developer needs to deal with. Every company that develops software will have multiple code branches active at the same time (unless they're small enough to fit in your garage.) Every developer will need to merge his changes forwards and backwards from time to time.

Subversion and CVS have historically given you very little help doing merges (although the situation has improved slightly recently.) This led to an attitude of superstition and fear towards branches. But if you don't understand branching and merging, you *will get burned*, no matter which VCS you use. It's better to just explain to people how things really work.

Printing this tutorial

seneca6 — Fri, 26 Feb 2010 16:06:08 +0000

Does anyone succeed in printing this tutorial in a nice form? If so, using what software? (I rarely
print articles, but this would be worth it.)

Hg Init: a Mercurial tutorial

cortana — Fri, 26 Feb 2010 09:43:46 +0000

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

Hg Init: a Mercurial tutorial

dlang — Fri, 26 Feb 2010 06:43:39 +0000

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.

git "too hard to use"?

mikov — Fri, 26 Feb 2010 01:24:46 +0000

The problem is not only the command line. (BTW, TortoiseGit sucks big
time).
Conceptually Git is much more complex than SVN or VSS. To use Git, even in
trivial scenarios, people need to understand branches, perform merges,
resolve conflicts, etc. Not to mention their reaction when they see the SHA
hashes :-)

Imagine the simplest case of a centralized SVN-like workflow. At the very
least it requires understanding of remote repository tracking, merging
or rebasing. If people don't understand what is really going on, they
invariably hit a wall sooner or later.

Don't get me wrong. I don't think this is a shortcoming of Git. Git is
conceptually complex, because it is conceptually very powerful, and I like
it that way. But that means that "regular people" may never be able to use
it adequately. I am not sure what the solution is. In fact I am not sure
that I want a solution :-)

Hg Init: a Mercurial tutorial

cortana — Fri, 26 Feb 2010 00:46:34 +0000

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.

git "too hard to use"?

cortana — Fri, 26 Feb 2010 00:41:22 +0000

As soon as you show these people the command line they get scared. Once Git has something as good as TortoiseSVN then it will be ready for them.

Hg Init: a Mercurial tutorial

brodie — Fri, 26 Feb 2010 00:19:34 +0000

Git actually "happened" at nearly the same time as Mercurial: Both were created by kernel hackers
for the kernel in April of 2005.

Hg Init: a Mercurial tutorial

oblio — Thu, 25 Feb 2010 22:37:46 +0000

Good for you. For most developers out there (and for most people), GUIs have surpassed CLIs for a long time. This is not the place to argue the merits of each.

I'm just pointing out that without a great GUI client, widespread usage, especially in companies, won't happen. And not all the world's projects are community projects ;)

hg/git vs svn/cvs: Just use git-svn

vonbrand — Thu, 25 Feb 2010 17:53:26 +0000

Yes, but that is cheating ;-)

Hg Init: a Mercurial tutorial

nye — Thu, 25 Feb 2010 17:49:32 +0000

I have never understood this. Back in the days before svn was entirely obsolete, I tried TortoiseSVN and found it confusing and difficult to use, especially when compared with the command-line where everything I wanted to do was trivial - both more obvious and far quicker than wrestling with the GUI.

Is it just for people who will always consider a GUI easier than a CLI, no matter how complicated the GUI and simple the CLI? Or is there just some complete disconnect in the way my brain works compared to the target audience? I find a lot of these GUI 'simplifications' so hard to use that I almost feel embarrassed to admit it.

git "too hard to use"?

vonbrand — Thu, 25 Feb 2010 17:48:34 +0000

How is git "a serious obstacle"? It used to be only for experts in arcana, but today it is much more (user)friendly. Try a recent (1.6 or later) version on your "technically unsavy" users before jumping to conclusions. And don't try to show them the whole toolkit, keep at the dozen or so most used commands.

hg/git vs svn/cvs

rfunk — Thu, 25 Feb 2010 17:45:49 +0000

"project maintainers who still believe svn/cvs/... are a good idea should be
the first against the wall for the pain they inflict on everyone else."

Not entirely -- with git-svn you can use git locally while working with a
subversion repository.

Hg Init: a Mercurial tutorial

djpig — Thu, 25 Feb 2010 16:05:31 +0000

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

Hg Init: a Mercurial tutorial

BenHutchings — Thu, 25 Feb 2010 14:06:48 +0000

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

Git on Windows

epa — Thu, 25 Feb 2010 12:17:10 +0000

For Windows users, the git-sharp implementation of Git may be useful. It is a reimplementation of the code in C# and might fit more easily into Windows-flavoured .NET applications. I don't believe any GUI front end has yet been written, however.

Hg Init: a Mercurial tutorial

mpr22 — Thu, 25 Feb 2010 10:14:33 +0000

There's nothing nuts about putting your new projects in the same source control system as your existing projects.

Hg Init: a Mercurial tutorial

bboissin — Thu, 25 Feb 2010 08:55:55 +0000

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

lmb — Thu, 25 Feb 2010 08:53:27 +0000

Arguing hg versus git is pointless, since it is a matter of taste and preference. (I personally prefer hg.)

But hg/git versus svn/cvs/... is a matter of sanity, and project maintainers who still believe svn/cvs/... are a good idea should be the first against the wall for the pain they inflict on everyone else.