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

Mercurial, 20 years and counting: how are we still alive and kicking? [video]

fosdem.org

Post reply on HN
Print view View original

221–230 of 263 posts

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#221

Post by spacechild1 »

unnah wrote: post #186
spacechild1 wrote: post #155

Earlier quoted context omitted.

> Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". Interesting, that's definitely not how I use git. My current code is rarely in a shape that can be fully committed. It often contains additional stuff I did on the way (small bug fixes, TODO comments, debug printf statements, etc.) that I don't want in the commit. Very rarely do I type `git add .` Am I the…

I don't see why there has to be a special staging area when you could just edit the HEAD commit instead. In git you could do "git commit --patch" to commit selected parts and then add more changes to the HEAD commit by "git commit --patch --amend".

Yes, I pretty much do the same thing with git-gui. You are right that the staging area isn't strictly necessary for this kind of workflow.

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#222

Post by spacechild1 »

throwaway613746 wrote: post #173
spacechild1 wrote: post #155

Earlier quoted context omitted.

> Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". Interesting, that's definitely not how I use git. My current code is rarely in a shape that can be fully committed. It often contains additional stuff I did on the way (small bug fixes, TODO comments, debug printf statements, etc.) that I don't want in the commit. Very rarely do I type `git add .` Am I the…

So you're just constantly committing untested versions of you work?

No.

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#223

Post by xeyownt »

txhwind wrote: post #166
bsder wrote: post #138

Earlier quoted context omitted.

> Is git really far worse technology than mercurial? Git is far worse simply because of "staging". "Staging" may be necessary (I do not concede this) in big projects, but in small projects it's an absolute disaster to the mental model. Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". In addition, Git's UX is hot garbage. I would constantly be doing rsync o…

I'm curious on the use of rsync in version control. What's the source and destination?

Yeah, this is insane. Show a complete lack of understanding on how the tool works.

Using rsync on git is like hammering a nail with a hammer, but then use a 10 pound stone to hammer the hammer.

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#224

Post by xeyownt »

martinpw wrote: post #165
dreamcompiler wrote: post #163

Earlier quoted context omitted.

I haven't lost data to git in a long time and I never rsync anything. But it took a long time to get to that point. Git is extremely predictable, but only after you thoroughly understand it. Until then, it seems to surprise you often and every time it happens you think you've lost data. Many times I've had collaborators who said "git ate my files" and I can usually get their files back in a few minutes. This makes th…

I've always felt bad about not understanding git better and wanted to dedicate time to learn it properly but never got to it. Finally this is a use case where AI is really good. It has always been able to get me out of trouble when I mess up, and often rescued files I thought I had lost for good. And is always able to rebase for me, normally a place where I flail pathetically. And it's easy to human verify the result…

The best recommendation is "Git Internals" (https://github.com/pluralsight/git-internals-pdf). It teaches you how git works from the internal, and give you absolute confidence and understanding on how the tool works.

I guess it'd take one day of your life to read it, but I think it pays back a lot.

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#225

Post by streetfighter64 »

Arainach wrote: post #169
streetfighter64 wrote: post #153

Earlier quoted context omitted.

Well I can explain git to anybody who understands a DAG. And mercurial is also based on the exact same data structure. So yes it would be very surprising if you didn't consider it to be "acceptable". The fact that there's lots of training data out there on strange git states is proof of exactly my point. Git is popular and thus used by lots of people who don't know the first thing about the command line, let alone da…

Mercurial doesn't require understanding a DAG. You can get by with `hg next`, `hg prev`, and `hg rebase -s -d ` to move entire chains of commits around. Commands with obvious names that allow moving around without understanding chains of dependencies. No weird states where you checkout an old commit but random files from where you just were are left in the directory tree for you to deal with. No difference between `c…

Look, I'm not commenting on which system has better named commands. My main points are

1) A DAG is not a difficult concept to understand (despite the "scary" name). If you can understand package dependencies or a manufacturing process you already understand it.

2) Learning git without knowing about the DAG, i.e. knowing what a commit even is, is counterproductive. It's like learning to drive a manual car without knowing what the clutch does. Sure you could probably teach someone that way, but why would you? What's the benefit to learning mercurial without understanding what a rebase actually does?

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#226

Post by harshreality »

MattJ100 wrote: post #206
spacechild1 wrote: post #155

Earlier quoted context omitted.

> Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". Interesting, that's definitely not how I use git. My current code is rarely in a shape that can be fully committed. It often contains additional stuff I did on the way (small bug fixes, TODO comments, debug printf statements, etc.) that I don't want in the commit. Very rarely do I type `git add .` Am I the…

To be clear, Mercurial does not have a staging area, but it does have allow selective commits (and selective uncommits) via prompt-based or interactive UI selection of hunks. Disagreeing with the need for a staging area is not the same as saying selective commits are unnecessary (I use Mercurial more than git and I rarely commit everything in my working directory in a single commit - I like small commits).

When there's an expectation or requirement that each commit builds (and even passes tests), how can you do partial commits? Do you work exclusively on projects without such requirements? Do you rely solely on CI to ensure that your commit compiles? Do you not use CI and not care if a commit is broken... you'll squash a fix in later, or not even squash it and leave a broken commit in the repo?

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#227

Post by qsera »

spacechild1 wrote: post #219
qsera wrote: post #194

Earlier quoted context omitted.

People make this claim but it never made sense to me. How do you know the version that you are committing is buildable if you never tried building with it? And if you tried building with it, you can just do `git add .` or `git add -u` at that point. So yes, your usecase does not make sense to me. There was another comment that said similar thing... https://news.ycombinator.com/item?id=48175289 >So you're just constan…

1. CI 2. Why should comments or printf statements affect the build? When it compiles with them, why shouldn't it compile without them? 3. the commits might be temporary and get squashed anyway

1. Not a very good reason. Some projects might have slow CIs. Some projects might not have a CI at all. Some project's CI might not be checking everything (front end for example)..

2. Because people make mistakes. You might think you are only excluding a comment, but might be excluding something that is required by mistake.

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#228

Post by adjejmxbdjdn »

nezi wrote: post #130
jjav wrote: post #52

Earlier quoted context omitted.

Mercurial is one of the many sad stories of far better technology being forgotten by the popularity contest juggernaut of something else. I still use mercurial for all my personal project where I don't need to care what anyone else thinks. It is pleasant to use good tools, just like I like to buy top quality rachets or such.

Is git really far worse technology than mercurial? I’ve used both for years and to be honest they are pretty similar. What important capabilities does hg have that git does not? Maybe you can argue that hg is more ergonomic, but that’s just polish it doesn’t mean the tech is far better…

If you think about how much investment has gone into Git, whereas Mercurial has really been developed by a skeleton team, even the fact that they’re similar is indicative that Mercurial may have been better at its core.

I haven’t touched mercurial in like 15 years, and from what I remember its UX was superior to what Git provides today. It had an extension system which I don’t remember the full capabilities of so I don’t know if Git has even now matched up to that.

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#229

Post by adjejmxbdjdn »

spacechild1 wrote: post #155
bsder wrote: post #138

Earlier quoted context omitted.

> Is git really far worse technology than mercurial? Git is far worse simply because of "staging". "Staging" may be necessary (I do not concede this) in big projects, but in small projects it's an absolute disaster to the mental model. Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". In addition, Git's UX is hot garbage. I would constantly be doing rsync o…

> Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". Interesting, that's definitely not how I use git. My current code is rarely in a shape that can be fully committed. It often contains additional stuff I did on the way (small bug fixes, TODO comments, debug printf statements, etc.) that I don't want in the commit. Very rarely do I type `git add .` Am I the…

Git add is a reflection of git commit being such a heavy operation.

It’s a pointless addition. Making commits easier to modify and undo would eliminate any need for git add.

But git can’t really do that since it’s so fundamentally based on the idea that commits are immutable. Any modifications r does allow are workarounds, and dangerous ones at that.

Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]

#230

Post by spacechild1 »

qsera wrote: post #227
spacechild1 wrote: post #219

Earlier quoted context omitted.

1. CI 2. Why should comments or printf statements affect the build? When it compiles with them, why shouldn't it compile without them? 3. the commits might be temporary and get squashed anyway

1. Not a very good reason. Some projects might have slow CIs. Some projects might not have a CI at all. Some project's CI might not be checking everything (front end for example).. 2. Because people make mistakes. You might think you are only excluding a comment, but might be excluding something that is required by mistake.

If I really want to make sure, I do:

1. git stash

2. build + test

3. commit

4. git stash pop

> Some projects might not have a CI at all.

Well, then you have bigger problems. Without CI, how would you even know if your projects compiles on other platforms?

Post reply on HN