| |||||||||||||
Hg Init: a Mercurial tutorialHg Init: a Mercurial tutorialPosted Feb 24, 2010 16:54 UTC (Wed) by realnc (guest, #60393)Parent article: Hg Init: a Mercurial tutorial
Is there actually a world after Git? Ever since Git happened, hg, svn, etc suddenly stopped making any sense.
(Log in to post comments)
Hg Init: a Mercurial tutorial Posted Feb 24, 2010 17:09 UTC (Wed) by tomsi (subscriber, #2306) [Link]
For a lot of us, it is mercurial that makes sense, not git ...
Not all software projects are as complex as the Linux kernel, not all developers need the complexity of git. Not all developers are using Linux either (unfortunately ;))
Hg Init: a Mercurial tutorial Posted Feb 24, 2010 17:27 UTC (Wed) by smadu2 (subscriber, #54943) [Link]
Very true. Git is too powerful and is overkill for projects in corporate
environment and not to mention lack of git plugins for various IDEs that people use. Its hard to convince people when they say why use something else when the current one is not broken - but thanks to git-svn and git-cvsimport devs can still use git and everybody wins.
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
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
one day, I believe they'll finally have the user interface to git cleaned
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
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
Don't get me wrong. I don't think this is a shortcoming of Git. Git is
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
The people I am referring to are not 'software developers'. I mentioned
Take the following example error message, which while technically very
"error: failed to push some refs to '....'
Refs? non-fast-forward? WTF?
Whether they have been 'damaged' by using 'inferior VCS' is
From experience, the lock-modify-unlock model and Visual Source Safe
I am thinking that the right solution to this kind of problem may be to
git "too hard to use"? Posted Feb 26, 2010 23:29 UTC (Fri) by ldo (subscriber, #40946) [Link] mikov wrote:
Yes they do. Since when do documentation writers not need to manage revisions to their documentation?
What are they doing using rebase? You should never use that on a branch that has been published for others to see.
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
> What are they doing using rebase? You should never use that on a branch
This is not the place and time to explain how Git works, but in short, if
> Thats not how the real world works. Even with common-or-garden office
I am sorry, but that it is nonsense. It is impossible to merge binary files
> Concepts of branches, tagging and merging are common to all modern
I am not interested in Git advocacy. As I mentioned earlier, I find Git
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
Second, partial writes are detected, hg asks you to use `hg recover`, which
Finally unpacked git repos might be very safe (you basically write a new
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.)
Hg Init: a Mercurial tutorial Posted Feb 24, 2010 17:34 UTC (Wed) by drag (subscriber, #31333) [Link]
Git really is not that complicated to use. I am quite happily using it and I never really figured
out how to use svn or cvs with any sort of competency. It actually seems quite easy to me to 'get'.
Like I don't have to give a crap about directory names, renaming files, or moving stuff around.
----------------
I do think though with the advent of Git it did make non-distributed ways to manage code
I am interested in things like Hg, though.
I am interested in using a distributed way to manage my desktop directory and Git is not
Hg Init: a Mercurial tutorial Posted Feb 24, 2010 17:49 UTC (Wed) by bjacob (subscriber, #58566) [Link]
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.
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
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:
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.
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
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
That's what receive.denyNonFastForwards is for.
Hg Init: a Mercurial tutorial Posted Feb 24, 2010 18:31 UTC (Wed) by jwb (guest, #15467) [Link]
This is crazy talk. There's plenty of room out there for more than one SCM.
The only thing that's really dead is subversion and CVS. People who use them on new projects (like my current employer, alas) must be nuts.
Hg Init: a Mercurial tutorial Posted Feb 25, 2010 10:14 UTC (Thu) by mpr22 (subscriber, #60784) [Link]
There's nothing nuts about putting your new projects in the same source control system as your existing projects.
git <=> hg Posted Feb 24, 2010 18:58 UTC (Wed) by alex (subscriber, #1355) [Link]
Actually given the similarities between git and hg it makes a fairly good
tutorial for git as well :-)
Hg Init: a Mercurial tutorial Posted Feb 24, 2010 20:51 UTC (Wed) by oblio (guest, #33465) [Link]
Does git have any robust Windows GUI clients? The killer app for version control isn't the server, it's the client. Kind of like TortoiseSVN - SVN :)
If anyone has hands on experience with a Windows GUI client that is
Hg Init: a Mercurial tutorial Posted Feb 24, 2010 23:26 UTC (Wed) by donblas (guest, #63860) [Link]
I find that TortoiseHg (http://mercurial.selenic.com/wiki/TortoiseHg) is a good GUI for Mercurial and is comparable with Tortoise SVN.
Hg Init: a Mercurial tutorial Posted Feb 25, 2010 17:49 UTC (Thu) by nye (guest, #51576) [Link]
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.
Hg Init: a Mercurial tutorial Posted Feb 25, 2010 22:37 UTC (Thu) by oblio (guest, #33465) [Link]
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 Init: a Mercurial tutorial Posted Mar 2, 2010 11:37 UTC (Tue) by nye (guest, #51576) [Link]
>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
Hg Init: a Mercurial tutorial Posted Mar 2, 2010 18:09 UTC (Tue) by oblio (guest, #33465) [Link]
> 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.
int main(void) {
To this one:
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 Posted Mar 3, 2010 12:55 UTC (Wed) by nix (subscriber, #2304) [Link]
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 Posted Mar 3, 2010 21:45 UTC (Wed) by oblio (guest, #33465) [Link]
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 Posted Feb 26, 2010 0:19 UTC (Fri) by brodie (guest, #63892) [Link]
Git actually "happened" at nearly the same time as Mercurial: Both were created by kernel hackers
for the kernel in April of 2005.
|
|||||||||||||
