Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mercurial developer responds to "Switch to git?"

groups.google.com

Post reply on HN
Print view View original

161–170 of 201 posts

Re: Mercurial developer responds to "Switch to git?"

#161

Post by mrtngslr »

steveklabnik wrote: post #81
kasey_junk wrote: post #63

Earlier quoted context omitted.

Just curious, what about Git's branches and history management is better than Mercurials with the appropriate plugins turned on? I've been able to successfully replicate all the Git use cases I can think of in Mercurial even if I think they are bad practices. Conversely, nothing I do makes git's cli anywhere near as good as hg. For me, that is the single biggest glaring problem with Git. I spend a very small minority…

I a not mega familiar with mercurial, but I was under the impression that culturally, rebasing is considered bad. Yes, there is a rebase plug-in, but mercurial users don't generally think it's a good idea to mutate history. Git users tend to branch, make a ton of commits, then clean them up using rebase and then merge and push. hg users tend to... not? I may be _entirely_ off base here. (personally I find git's comma…

I think the view you present here is outdated. Today, rebasing is used a lot by Mercurial users. Even for the development of Mercurial itself, rebasing is not considered bad, it's considered a requirement for submitting a patch series. That is, the patches are sent by email and applied with 'hg import', and thus implicitly rebased. If that causes too many merge conflicts, you will be asked to rebase it yourself and resubmit it.

Mutating history is front and center in the changeset evolution framework people have been working on for some years now. The first step is that Mercurial tracks when it's safe to rebase or edit a commit: each commit has a "phase" which is "draft" initially, but changes to "public" when you push the commit somewhere. The history editing tools ('hg rebase', 'hg histedit', 'hg commit --amend') will then tell you when it's unsafe to edit a commit.

Re: Mercurial developer responds to "Switch to git?"

#162

Post by mrtngslr »

qznc wrote: post #137
ggchappell wrote: post #33

Articles like this worry me a lot. Most of this post leaves me thinking, "Why should I be worrying about things like this?" A fair amount of it leaves me at least somewhat boggled; I suspect I'm not alone here. The idea that a user of a DVCS needs to be familiar with issues like these tells me that something is seriously wrong with the design of DVCSs. Remember, a DVCS is a tool we use to track and store data related…

Software development with more than one person is inherently a distributed system. People work on outdated versions and in parallel and conflicts arise. Development requires branching and merging. It is probably impossible to package this complexity into an easy UI. I like git, because it has a simple core model, but the UI could certainly be easier. Mercurials model is not so simple (e.g. multiple types of branches…

There is only one type of commit in Mercurial. Please don't suggest otherwise.

The commits form a directed acyclic graph (a DAG) and you expand the graph when you make new commits. Subsets of the graph can be said to belong to the same branch (a named branch, the ones you create with "hg branch"). By default all commits belong to the branch named "default".

Any given subset of the commit DAG might have multiple heads (commits with no children), e.g., the subset of the DAG that is the "default" branch might have multiple heads representing multiple features that haven't been merged yet.

To help you pick the right head when you update, diff, etc, you can give it a name — you add a bookmark to the head. The bookmark is just like a post-it you stick on your monitor saying "commit e9ade5b11421 is better known as fix-broken-build". It's just an alias for the commit ID, in the same way that a Git branch name is a convenient name for a commit.

To be useful, bookmarks move when you make new commits. After 'hg update fix-broken-build', a 'hg commit' will move the "fix-broken-build" bookmark so it points to the newly created commit. This is again very similar to how a Git branch pointer will advance when you run 'git commit'.

I hope that helps a bit!

Re: Mercurial developer responds to "Switch to git?"

#163

Post by luastoned »

emn13 wrote: post #20
_stephan wrote: post #15

Earlier quoted context omitted.

Have you tried it in the last few days? After SourceTree got relatively slow for me with the past few updates, the last update actually completely fixed that!

I use SourceTree for git, but I find TortoiseHg is better for mercurial; it's just far more feature complete, with support for almost all mercurial commands and (bundled) extensions. I'm still somewhat surprised by how poor git gui's are, considering it's the more popular VCS - though SourceTree is certainly one of the better ones.

I was really happy when I heard about SourceTree(back then it was not even released yet) but when it finally came out it was bulky to begin with.

TortoiseHg on the other hand always looked nice and clean.

Re: Mercurial developer responds to "Switch to git?"

#164

Post by mrtngslr »

Mithaldu wrote: post #152
jheriko wrote: post #14

i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good. "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " I find it hard to understand what this means, but this is typical of the arguments i see for using git. really the core concepts of DVCS are the same no matter what tool you use,…

> "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " > > I find it hard to understand what this means The git model can be, to a sufficient degree of completeness, be demonstrated with child toys: http://www.youtube.com/watch?v=1ffBJ4sVUb4 I can't even imagine how a similar demonstration would look like with Mercurial. It would…

Please see this figure: http://www.aosabook.org/en/mercurial.html#fig.hg.revlog

I hope you see the similarities between the storage layers of Mercurial and of Git: Mercurial has a changeset graph with pointers into a manifest graph. The nodes in the manifest graph points to the files presents in that commit. It's (also) not very complicated.

As for branches, they're very simple too, as I tried to explain here: https://news.ycombinator.com/item?id=6753477

Re: Mercurial developer responds to "Switch to git?"

#165

Post by mrtngslr »

MAGZine wrote: post #27
jheriko wrote: post #14

i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good. "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " I find it hard to understand what this means, but this is typical of the arguments i see for using git. really the core concepts of DVCS are the same no matter what tool you use,…

Nobody is saying you have to squash, it's just recommended to tidy changehistory. For all of your projects, you can simply not squash, and ask contributors to do the same. It's not like git rewrites history automatically... Just because git will let you shoot yourself in the foot, doesn't mean that it's a tool that should be avoided.

Agreed... rewriting history is a powerful tool that power users will want to use. Nothing more. That of course applies to all tools :)

Re: Mercurial developer responds to "Switch to git?"

#166

Post by reinhardt »

ams6110 wrote: post #55
ggchappell wrote: post #33

Articles like this worry me a lot. Most of this post leaves me thinking, "Why should I be worrying about things like this?" A fair amount of it leaves me at least somewhat boggled; I suspect I'm not alone here. The idea that a user of a DVCS needs to be familiar with issues like these tells me that something is seriously wrong with the design of DVCSs. Remember, a DVCS is a tool we use to track and store data related…

Articles like this make me wonder if I'm stupid. 95% of the time all I ever do is commit my work and push/pull, whether I'm using svn, git, or hg. I just hardly ever find myself needing to understand anything more complicated than that. Why does it seem like everyone else has spent thousands of hours understanding esoteric git or hg incantations that I've never encountered the need for.

> all I ever do is commit my work and push/pull, whether I'm using svn, git, or hg.

And yet, even those simple operations are different between different DVCS. 'hg pull' and 'git pull' are not equivalent, same with push. I try to stay away from git but when I can't avoid it, I have to remember that the sane/safe way to pull in git is apparently 'git pull --ff-only'.. #fail

Re: Mercurial developer responds to "Switch to git?"

#167

Post by naitbit »

gbog wrote: post #135
ams6110 wrote: post #55

Earlier quoted context omitted.

Articles like this make me wonder if I'm stupid. 95% of the time all I ever do is commit my work and push/pull, whether I'm using svn, git, or hg. I just hardly ever find myself needing to understand anything more complicated than that. Why does it seem like everyone else has spent thousands of hours understanding esoteric git or hg incantations that I've never encountered the need for.

Maybe you could let git influence and hopefully improve the way you work. For instance, when refactoring something quite complex with good test coverage, you want each commit to be the smallest atomic commit that can pass all tests. But you also want to very quickly and "carelessly" add debug logs, assertions, changes in many files. For this kind of task I have found the following workflow to be very helpful and fast…

I'm sure that git with it's very powerfull backend has way for improving way someone works, but I'm not convinced by this example. IMO it shows again that usability of git is far from perfect. For example in bzr to accomplish this task you can:

1. (same)

2. (same)

3. put all changes that you are not interested in on shelve: `bzr shelve` (or qshelve if you want QT gui)

4. Run full test suite

5. If 4. fails keep editing

6. If 4. pass `bzr commit` (or `bzr ci`), and to revert shelving use `bzr unshelve`

You need to remember 6+ git command to accomplish this tasks, and only 3 with bzr. Moreover there is symmetry in bzr (fe: shelve - unshelve, commit - uncommit) that is no present in git.

edit: formatting

Re: Mercurial developer responds to "Switch to git?"

#168

Post by Grue3 »

mrtngslr wrote: post #158
natrius wrote: post #96

Earlier quoted context omitted.

To use bookmarks, I have to convince the whole team to use bookmarks. Why not convince them to switch to git instead? I use Mercurial plugins to give me commands that make my life better, like `pull --rebase`, `shelve` and `strip`, but getting coworkers on the bandwagon requires explaining which extensions to install instead of pointing to the man page for the appropriate command. My git workflow is probably replicab…

(OP here) You don't need to tell the rest of the team if you're using bookmarks, just like you don't need to tell the rest of your team the names of your Git branches. Bookmarks stay local by default, but they can be exported to the server if you like. There's nothing to enable any longer since it's a core feature.

Mercurial also has named branches. Which suck. I'd rather use bookmarks, but my team uses named branches, so that's what I have to use as well. This problem wouldn't exist with git.

Re: Mercurial developer responds to "Switch to git?"

#169

Post by ryanbrunner »

jlgreco wrote: post #45
tednaleid wrote: post #42

Earlier quoted context omitted.

That's not correct, you can get back to any ref in the reflog, including those that you moved away from with git-reset --hard. Those commits are just dangling but are easy to get back to. I've got a presentation [1] that goes into how to use the reflog and how the various flags in reset work (among other things) that could explain more. [1]: http://tednaleid.github.io/showoff-git-core-concepts/

My point is that git-reset --hard can remove data from the working tree filesystem that never hit the DAG in the first place: $ git init Initialized empty Git repository in /home/john/tmp2/.git/ $ echo "foo" > foo $ git add foo $ git commit -m 'init' [master (root-commit) 84fb5d1] init ... $ echo "bar" >>foo $ cat foo foo bar $ git reset --hard HEAD HEAD is now at 84fb5d1 init $ git reflog 84fb5d1 HEAD@{0}: commit (i…

git reset --hard at least has the benefit of sounding like it's going to do something scary. "git checkout ." will also completely nuke your working directory without warning, and looks benign enough that you would never expect that problem.

Which really, at the end of the day, is the real problem with git. It's not that it's inherently more dangerous, it's that the CLI is so inconsistent it can be hard to remember what you're doing, what's safe and unsafe, etc. Sometimes you need to pass "--force" for dangerous stuff, sometimes you capitalize the argument (like force deleting a branch). Sometimes "--hard" indicates that you should do the dangerous version of something. Sometimes there's not even a safety switch.

Re: Mercurial developer responds to "Switch to git?"

#170

Post by cnvogel »

thaumasiotes wrote: post #120
jlgreco wrote: post #57

Earlier quoted context omitted.

Even when powering electronics in the home, you have to worry about which sort of power the device needs. Does it need a great big 240V AC outlet, or just the regular 120V AC (using American values...)? Is the device DC powered instead? Does it have it's own wall-wart, or can you use a AC->USB converter? Does it use USB micro or mini? These are things the consumer has to worry about. Of course in practice "worry abou…

> Even when powering electronics in the home, you have to worry about which sort of power the device needs. Does it need a great big 240V AC outlet, or just the regular 120V AC (using American values...)? This isn't accurate as to the electronics that I use. All the adapters say "input 120 - 240V". Non-portable electronics tend to be compatible with the plugs in the same area where you buy them... since they're not p…

The parent comment didn't refer to the 120V / 240V distinction because of the voltage itself, but rather refers to two distinct kinds of electrical sockets.

120V = NMEA-5, 240V = NMEA-6 http://en.wikipedia.org/wiki/NEMA_connector

When you install a washing machine (or, for example a circular saw in your workshop) you'll have to make sure that the proper socket is available at the place where you want to put it (or you'll have to install one at that location).

In Europe, the corresponding comparison would be between 1-phase (230V) power and 3-phase (400V) power, e.g. normal household socket and the red, round 5-prong CEE connectors.

http://de.wikipedia.org/wiki/CEE-System

Post reply on HN