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

Why a small team chose Mercurial.

ninthdivision.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Why a small team chose Mercurial.

#21

Post by schumihan »

pacemkr wrote: post #20

I've been using Mercurial for a few years and am now turning to git (one week in, so I won't say much about it) for a very specific and fundamental reason: short lived local branches. Say you have a repository, fix a few bugs on it, and now you want to work on a crazy feature. What you need is a short lived local branch, because you don't know if crazy feature even makes sense. Unfortunately, there is no built in way…

I use patch queue[1] to manage these short lived branch, and it works for my purpose. You just pop the patches and delete them all when you want to prunge the branch. It also make it easy for others to review your code.

If these short-lived branch will be merged back shortly. Bookmark is another alternatives.

[1] http://mercurial.selenic.com/wiki/MqExtension [2] http://mercurial.selenic.com/wiki/BookmarksExtension

Re: Why a small team chose Mercurial.

#22

Post by megaman821 »

pacemkr wrote: post #20

I've been using Mercurial for a few years and am now turning to git (one week in, so I won't say much about it) for a very specific and fundamental reason: short lived local branches. Say you have a repository, fix a few bugs on it, and now you want to work on a crazy feature. What you need is a short lived local branch, because you don't know if crazy feature even makes sense. Unfortunately, there is no built in way…

Mercurial bookmarks are roughly equivalent to Git branches. They are local only unless you explicitly push them and you can delete them when done.

Re: Why a small team chose Mercurial.

#23

Post by pacemkr »

schumihan wrote: post #21
pacemkr wrote: post #20

I've been using Mercurial for a few years and am now turning to git (one week in, so I won't say much about it) for a very specific and fundamental reason: short lived local branches. Say you have a repository, fix a few bugs on it, and now you want to work on a crazy feature. What you need is a short lived local branch, because you don't know if crazy feature even makes sense. Unfortunately, there is no built in way…

I use patch queue[1] to manage these short lived branch, and it works for my purpose. You just pop the patches and delete them all when you want to prunge the branch. It also make it easy for others to review your code. If these short-lived branch will be merged back shortly. Bookmark is another alternatives. [1] http://mercurial.selenic.com/wiki/MqExtension [2] http://mercurial.selenic.com/wiki/BookmarksExtension

I'm aware of both. Personally I find this to be an inferior solution. Using a patch queue as a local branch just feels wrong. Neither is using bookmarks an effective solution. Both solution make the decision to branch a much more deliberate process, and in the end you still don't get a branch that is equal to its peers.

As the result, in hg, you have to decide in advance "what kind of branch" it will be -- or you have to get in the habit of using mq's for everything -- and this just not a natural experience especially for a DVCS where branching is just fundamental.

Re: Why a small team chose Mercurial.

#24

Post by p_nathan »

dlsspy wrote: post #4

This misconception always bothers me: "In Mercurial you can’t change previous committed code. In git you can change the past commits in the repo. I am sure there are cases where the linux kernel needs to do this (I can’t think of any), but this is some we don’t even want to have the option to do." Yes, you certainly can change commits in hg. The tools to do it in git are a bit more refined, but there's no fundamental…

If it's important enough to be committed, it's important enough to be remembered.

Re: Why a small team chose Mercurial.

#25

Post by 100k »

jackowayed wrote: post #16
100k wrote: post #13

Earlier quoted context omitted.

It is trivial in Mercurial to back out the last commit: hg rollback I use it all the time to fix typos, add a file I forgot to add, or whatever. Once you push, it is more difficult, but I try not to push my code until it works. I also commit only tested chunks of code, so that is the "unit of work" I aim for. The equivalent in git is something stupid, I have to look it up every time: git reset --soft HEAD^ That's int…

git reset HEAD^ (soft is the default option) is actually pretty intuitive once you're used to git. You're reseting the index to the state it was one commit ago (which is what HEAD^ means. That comes up a lot.) And if you really forget it often, add this to your ~/.gitconfig: [alias] rollback = reset HEAD^ Now you can run `git rollback`

I know what HEAD^ (and HEAD^^^^^ or whatever) mean.

The fact that I have to make aliases for commonly used tasks is not a point in git's favor to me.

Re: Why a small team chose Mercurial.

#26

Post by 100k »

pacemkr wrote: post #20

I've been using Mercurial for a few years and am now turning to git (one week in, so I won't say much about it) for a very specific and fundamental reason: short lived local branches. Say you have a repository, fix a few bugs on it, and now you want to work on a crazy feature. What you need is a short lived local branch, because you don't know if crazy feature even makes sense. Unfortunately, there is no built in way…

I love Mercurial, but I agree with this. I tried using the bookmarks extension with a colleague who wanted to use branches this way and we had trouble figuring it out. Definitely not as easy as git (though getting new remote branches with git is another thing that drives me crazy and I have to look up every time).

git stash is another thing I really like about git. There are hg alternatives but they are not as easy to use (and if you go the mq route things become so complicated you might as well just use git).

Re: Why a small team chose Mercurial.

#27

Post by dlsspy »

100k wrote: post #25
jackowayed wrote: post #16

Earlier quoted context omitted.

git reset HEAD^ (soft is the default option) is actually pretty intuitive once you're used to git. You're reseting the index to the state it was one commit ago (which is what HEAD^ means. That comes up a lot.) And if you really forget it often, add this to your ~/.gitconfig: [alias] rollback = reset HEAD^ Now you can run `git rollback`

I know what HEAD^ (and HEAD^^^^^ or whatever) mean. The fact that I have to make aliases for commonly used tasks is not a point in git's favor to me.

Do you really uncommit that frequently? I just either amend my commits or keep adding new commits and squash them later.

The point is that you can make just about any workflow with git. The ones that git users less commonly use may not be have easy toplevel commands. People already complain about how many toplevel commands there are with git.

Re: Why a small team chose Mercurial.

#28

Post by dlsspy »

p_nathan wrote: post #24
dlsspy wrote: post #4

This misconception always bothers me: "In Mercurial you can’t change previous committed code. In git you can change the past commits in the repo. I am sure there are cases where the linux kernel needs to do this (I can’t think of any), but this is some we don’t even want to have the option to do." Yes, you certainly can change commits in hg. The tools to do it in git are a bit more refined, but there's no fundamental…

If it's important enough to be committed, it's important enough to be remembered.

Do you make the same judgment about saving files? If it's important enough to be saved to the filesystem, it's important enough to be remembered forever?

What about general edits in your editor? If it's important enough to have been typed so undo in my editor works, it's important enough to be part of the project history so someone else can see my typos when they're (as I've heard used as an argument for why you should never squash commits) tracking down a bug they can figure out the train of thought that led to that work?

Re: Why a small team chose Mercurial.

#29

Post by Legion »

indspenceable wrote: post #5

Pretty good; liked that they didn't just say "HG GOOD, GIT BAD". I'm confused about the git learning curve though; I started using git on my own this summer, and I was able to immediately pick up the commands I needed to get by literally the day I started. I'll admit I don't have to host repositories, like they would in for their company; but for simply using git as a developer it was very painless.

Some of git's learning curve reputation is historical. Some good effort as been put into making git less arcane.

Re: Why a small team chose Mercurial.

#30

Post by sjs »

p_nathan wrote: post #24
dlsspy wrote: post #4

This misconception always bothers me: "In Mercurial you can’t change previous committed code. In git you can change the past commits in the repo. I am sure there are cases where the linux kernel needs to do this (I can’t think of any), but this is some we don’t even want to have the option to do." Yes, you certainly can change commits in hg. The tools to do it in git are a bit more refined, but there's no fundamental…

If it's important enough to be committed, it's important enough to be remembered.

What about rewriting a topic branch before merging it?
Post reply on HN