Hg Init: a Mercurial tutorial [LWN.net]

Hg Init: a Mercurial tutorial

Posted Feb 24, 2010 17:36 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

Too powerful? That's like saying Linux is too powerful for corporation and
hence they should use Windows! You don't need to know all the different
commands to use git in a basic way

Which IDE's lack git support while supporting hg?

Hg Init: a Mercurial tutorial

Posted Feb 24, 2010 17:46 UTC (Wed) by smadu2 (subscriber, #54943) [Link]

I have seen people complaining when some one does push -f or rebase the
history with out letting other devs know about it etc etc I can go on ... I
agree that most of the time its people's fault for not following set
practices. I am not at all against git infact its the only one I use.

Hg Init: a Mercurial tutorial

Posted Feb 24, 2010 18:16 UTC (Wed) by emk (guest, #1128) [Link]

It's a good idea to configure your shared repositories to only allow fast-
forward pushes. This will prevent people from messing around with rebasing.

(We actually do allow a small amount of rebasing on certain projects at
work, but generally only on branches, and only when everybody involved has
adequate git-fu.)

Hg Init: a Mercurial tutorial

Posted Feb 24, 2010 19:10 UTC (Wed) by astrophoenix (guest, #13528) [Link]

does git have windows support? last I knew, it didn't. I hate windows, but
I work in a place where 80% of the devs use windows as their desktop. we
are currently adopting mercurial, because the windows folks can use
tortoiseHG.

that part aside, I can tell you that I've tried to learn git a couple
times, and it's hard. I know if I stuck with it I could learn it, but I
have to deal with low-level devs who don't even really understand why we
should be using a VCS in the first place.

one day, I believe they'll finally have the user interface to git cleaned
up to where it is easier to learn. until then, thank goodness for hg.

Hg Init: a Mercurial tutorial

Posted Feb 24, 2010 19:29 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

Yes, git supports windows in two ways

1. you can run it under cygwin

2. you can run the msysgit (I think that's it's name) which is a windows native implementation of git.

Hg Init: a Mercurial tutorial

Posted Feb 24, 2010 20:09 UTC (Wed) by dkrawchuk (subscriber, #21896) [Link]

msysgit gets you git plus the full mingw and msys. There is also a git port with just enough msys stuff to function properly.

Hg Init: a Mercurial tutorial

Posted Feb 24, 2010 21:36 UTC (Wed) by paulj (subscriber, #341) [Link]

There's a native Java port of git at that. See http://www.jgit.org/. It's
used by Eclipse, amongst others.

Git on Windows

Posted Feb 25, 2010 12:17 UTC (Thu) by epa (subscriber, #39769) [Link]

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.

Git on Windows

Posted Feb 24, 2010 20:26 UTC (Wed) by rfunk (subscriber, #4054) [Link]

There's also a TortoiseGit.

That said, I'm acquainted with a Windows guy who's used to TortoiseSVN and
stubbornly refuses to switch to git. (He tried it and didn't like it.) And
he likes to make changes on the production server.

Git on Windows

Posted Feb 24, 2010 21:47 UTC (Wed) by mikov (subscriber, #33179) [Link]

As a heavy Git user, my opinion about TortoiseGot is extremely negative.
I recently had to try TortoiseGit for another team member who is not so fluent in the command line and I think that it is a horrible abomination. It makes Git look bad and more complex than it is. I have been using Git for years and I like to think I know its ins and out; yet, I couldn't figure out how to do simple things with TortoiseGit.

Hg Init: a Mercurial tutorial

Posted Feb 24, 2010 21:52 UTC (Wed) by mikov (subscriber, #33179) [Link]

Alas, I also think Git is too powerful. While I love it and use it almost exclusively, teaching people to use Git can be a painful slow process. Not everybody has time or even interest in learning a new SCM.

Understanding Git can certainly be expected from developers - if they can't figure Git, they should look for a another job, or at least I certainly don't want them on my team. However there are parts of the team that need not be so deeply technical, and yet have to interact with source control. Documentation writers, web designers, testers, etc. For them Git is a serious obstacle.

git "too hard to use"?

Posted Feb 25, 2010 17:48 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

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.

git "too hard to use"?

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

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.

git "too hard to use"?

Posted Feb 26, 2010 1:24 UTC (Fri) by mikov (subscriber, #33179) [Link]

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

git "too hard to use"?

Posted Feb 26, 2010 19:06 UTC (Fri) by cmccabe (guest, #60281) [Link]

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.

git "too hard to use"?

Posted Feb 26, 2010 20:11 UTC (Fri) by mikov (subscriber, #33179) [Link]

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

Posted Feb 26, 2010 23:29 UTC (Fri) by ldo (subscriber, #40946) [Link]

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.

git "too hard to use"?

Posted Feb 27, 2010 0:23 UTC (Sat) by mikov (subscriber, #33179) [Link]

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

Posted Feb 28, 2010 20:25 UTC (Sun) by cmccabe (guest, #60281) [Link]

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

git "too hard to use"?

Posted Feb 27, 2010 15:05 UTC (Sat) by man_ls (subscriber, #15091) [Link]

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.

Hg Init: a Mercurial tutorial

Posted Feb 24, 2010 17:36 UTC (Wed) by lambda (subscriber, #40735) [Link]

Where has the meme about Git not being suitable for the corporate environment come from? There's nothing that makes it any less suitable than any other revision control system. You can have a central repository that everyone pushes to, and anyone who keeps things in private repos for too long without pushing is no different than anyone keeping changes in private checkouts for too long without pushing in any other revision control system.

What IDEs have Mercurial plugins but not Git at the moment?

And what does it mean for something to be "too powerful"? I've always found more powerful tools to be preferable to less capable ones. "Too confusing" or "too dangerous" might be valid criticisms, and might be what you're trying to imply, but being powerful does not necessarily imply them. I have found Git to be a bit confusing for inexperienced developers at times, but never found it to be particularly dangerous, as you almost always have some form of history you can revert to if you make a mistake.

Hg Init: a Mercurial tutorial

Posted Feb 24, 2010 17:50 UTC (Wed) by smadu2 (subscriber, #54943) [Link]

Too powerful == dangerous. On the other hand I do not find git confusing but
intuitive once you get hang of it.

repository format?

Posted Feb 25, 2010 0:57 UTC (Thu) by dmarti (subscriber, #11625) [Link]

Keith Packard wrote a while ago, "Mercurial uses a truncated forward delta scheme where file revisions are appended to the repository file, as a string of deltas with occasional complete copies of the file (to provide a time bound on operations). This suffers from two possible problemsthe first is fairly obvious where corrupted writes of new revisions can affect old revisions of the file. The second is more subtle system failure during commit will leave the file contents half written. Mercurial has recovery techniques to detect this, but they involve truncating existing files, a piece of the Linux kernel which has constantly suffered from race conditions and other adventures."

Is this still the case? I still feel less nervous about putting potentially long-lived projects into git, but maybe I have nothing to worry about with hg.

repository format?

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

It was never the case, it just shows a lack of knowledge as to how hg work
(this blog entry was considered a bit FUD'ish at that time).

First a corrupted write doesn't affect old revisions (that's the whole
point
of the append only design of hg, maybe he is mistaking hg format with svn,
where I think one of the format does the delta the other way round).

Second, partial writes are detected, hg asks you to use `hg recover`, which
truncates the files. During the (already) almost five years where I've been
involved in hg, I've never seen a single case of problem with truncate. The
scariest things I've seen were with xfs where after a hard failure and a
reboot, the repo would be in a state where files that where written
disappeared (git would have the same problem as hg in that case).

Finally unpacked git repos might be very safe (you basically write a new
file for every version of every file) but not space efficient (the repo
grows quickly). 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).

repository format?

Posted Feb 26, 2010 21:42 UTC (Fri) by bfields (subscriber, #19510) [Link]

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