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

231–240 of 263 posts

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

#231

Post by spacechild1 »

harshreality wrote: post #226
MattJ100 wrote: post #206

Earlier quoted context omitted.

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?

Is there an equivalent to `git stash` in Mercurial?

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

#232

Post by Netch »

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".

A normal situation in my tasks is when the working copy contains lots of changes that are used for debug (mainly prints) but these changes shall not be committed to the proposed change. For this, even interactive adding (`git add -i`) does not satisfy; I need `git add -e` which allows editing in a patch form, and remove the temporary local changes.

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

#233

Post by adjejmxbdjdn »

harshreality wrote: post #226
MattJ100 wrote: post #206

Earlier quoted context omitted.

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?

Why would partial commits necessarily break anything?

In fact, often partial commits are necessary for builds.

As an example (and to be fair, this was a transitional project), I once worked on a project where the local dev directly acquired packages from different parts of the application, but the actual CI was broken up into different pipelines which required some parts to be built first, its outputs packaged and added to the registry, and downstream parts to be built after.

Committing everything at once would literally break the CI.

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

#234

Post by homebrewer »

hyperrail wrote: post #175
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…

My use of `git add` - and the explicit staging area more generally - is mostly a workaround for the fact that the repos I work with have checked-in dev setup scripts, IntelliJ/Visual Studio/Xcode/VS Code configurations, and so on. My own setup differs in slight ways from what those scripts expect, and even where they match I like to do my own customizations. I don't want to commit those changes, and staging makes it…

You can ignore them once and then edit to your liking, git will not notice any changes to them and will assume them to be untouched.

https://git-scm.com/docs/git-update-index#Documentation/git-...

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

#235

Post by adjejmxbdjdn »

spacechild1 wrote: post #231
harshreality wrote: post #226

Earlier quoted context omitted.

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?

Is there an equivalent to `git stash` in Mercurial?

Yes. Shelve.

But there are also other extensions that can achieve similar behavior.

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

#236

Post by homebrewer »

Arainach wrote: post #78
loeg wrote: post #56

Earlier quoted context omitted.

Mercurial wasn't the better technology, though. The UX is almost the same as git, diverging in ways that are arguably worse, but the tools were written in much slower Python (initially, and for many years after).

How do you consider the UX "nearly identical" or "arguably worse"? The Mercurial CLI has clear, well named commands that are predictable and easy to memorize. hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively. The Git CLI requires you to understand its internal data structures to understand the difference between a rebase and a merge, a…

I've never rm-rf'ed a git repo (why would you voluntarily remove the reflog?) while also being a very mid-tier developer. The types that do also tend to reboot machines every time something goes wrong instead of looking for the exact cause of the problem and fixing it once and for all; to screw around with SQL (move subqueries here or there, add and remove indexes at random) until it runs acceptably instead of building proper understanding of how their database works, and so on. At least judging by what I've seen. Not really something to be proud of.

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

#237

Post by qsera »

spacechild1 wrote: post #230
qsera wrote: post #227

Earlier quoted context omitted.

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?

When I really want to do your workflow, here is what I do. Add all the debugging print statements and commit them separately in another branch. When I want to include the debug statements, I just cherry-pick the commit with those things.

This way I remove the overhead of doing a staging before every damn commit and still retain the ability to pull in debugging changes whenever I want them.

>Without CI, how would you even know if your projects compiles on other platforms?

Not everything need to be cross platform! And not everything need CI..

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

#238

Post by ciupicri »

thfuran wrote: post #113
ciupicri wrote: post #77

Earlier quoted context omitted.

I don't know what you mean by ergonomics, but I remember trying both Mercurial and Git back in the days after using Subversion before. I didn't like how Mercurial didn't easily let me rewrite history and do stuff like `git commit --ammend` or `git rebase`. Mercurial users kept telling me using an extension to manage patches on top of Mercurial (I think it was quilt). I agree about the Windows support. hg serve was al…

Mercurial does let you amend commits like git does, histedit is essentially identical to rebase -i, and evolve is better than anything git has.

Isn't histedit [1] an extension? I don't think it was available back then, or if I tried I didn't like it.

I don't remember evolve [2] at all.

[1]: https://repo.mercurial-scm.org/hg/help/histedit

[2]: https://repo.mercurial-scm.org/hello/help/evolve

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

#240

Post by ezst »

myst wrote: post #171
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…

Apparently the world went dumber in the last 20 years and staged commits are DIFFICULT now.

Both things can be true (the second being that staging was never necessarily not a desirable abstraction in light of easily and safely amendable commits)
Post reply on HN