Why a small team chose Mercurial.

Post by ldh » Sun, Jan 16, 2011, 6:01 PM UTC

epynonymous wrote: post #10

altogether a means to an end, mercurial and git are both good. i personally use mercurial. have worked with git in the past and was having trouble with the gerrit web front end and the fact that it required java. i also use bitbucket and since having been bought by atlassian, was able to get lots of free private repositories. i think some people mentioned that they accidentally left cookie secrets in their code on a…

The fun thing about lightweight, painless branching is that once you start to incorporate that into your workflow, it's never too early in a project to use it. Lately every new feature or fix I start to work on begins its life in a topic branch. You never know when you're going to be interrupted or need to switch contexts to work on something else (or even just scrap the whole idea) so having your repository mirror your mental process in a completely seamless way is invaluable.

Post by Rusky » Mon, Jan 17, 2011, 1:56 PM UTC

dlsspy wrote: post #12

Rusky wrote: post #6

Earlier quoted context omitted.

The difference is not fundamental, no. It is a difference in philosophy and interface that discourages modifying history. The question is: Why would you commit (to a stable branch) when your code doesn't build or pass tests? Why would you want to eliminate a state where you made something that worked? I don't see the appeal in modifying history. If you just need to save some partially working state, etc. you can use…

> The question is: Why would you commit (to a stable branch) when your code doesn't build or pass tests? Because: a) It's not a stable branch. It's my dev branch on my local box that nobody else can see. b) I feel like it and there's no penalty. I can go back if something is wrong. c) The next thing I'm going to do is risky. I should save where I am just in case I'm wrong. > Why would you want to eliminate a state wh…

> c) The next thing I'm going to do is risky. I should save where I am just in case I'm wrong.

a and b are not really reasons /to/ commit a broken state. On c: If the next thing you're going to do is dangerous, I'd say it's a separate "thing" and either 1) commit the stuff you have in a working state or 2) shelve/stash/qimport it if it's not done and you need to do the dangerous work first, which is why I mentioned patch queues.

Thus, purposeful broken commits are eliminated.

> I don't see the appeal in a history full of "Oops, I forgot to add this file to the last commit," and "build fix" and "The author wrote this on Solaris, but I need a small change in the Makefile for Linux."

hg rollback/backout are intended for "oops, I forgot to add this file to the last commit." There's no need to leave those commits in, unless the problem isn't discovered for a while, which is when modifying history makes sense.

Patch queues are most definitely not just "the tool I was offered." They are a rather powerful way to deal with commits as a stack, and I've never been bogged down "capturing state of work in progress."

---

There's nothing really wrong with git's workflow, but there's nothing wrong with mercurial's either. That's all I'm saying - "it is a difference in philosophy and interface that discourages modifying history" that I happen to prefer.

Re: Why a small team chose Mercurial.

Re: Why a small team chose Mercurial.