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

241–250 of 263 posts

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

#241

Post by kccqzy »

Mashimo wrote: post #200
kccqzy wrote: post #102

Earlier quoted context omitted.

I’ve never met a single person who can use git to move a commit and its descendants from one parent to another. This requires using the extremely unintuitive `git rebase --onto A B C` invocation. The only exception are magit users who are dealing with a much better interface and a better name (magit calls it rebase subset rather than onto). In contrast every single mercurial user I know can intuitively use `hg rebase…

Is that a common usecase? I think the way I would do it, is to go to target branch, cherry pick the commits and push. Then go to source branch and revert the changes. All done from within the IDE. Not the cleanest way, though.

Incredibly common when you write code faster than your colleague or manager can review them. You always have lots of branches and sometimes the branches implement interrelated functionality.

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

#242

Post by spacechild1 »

qsera wrote: post #237
spacechild1 wrote: post #230

Earlier quoted context omitted.

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…

This sounds more complicated overall. Also, I would still need the staging area to only commit the debug statements.

As I said, I like to work on several things in parallel and I don't want to switch branches back and forth. That's just my workflow for my own projects and apparently I'm not alone.

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

#243

Post by dreamcompiler »

xeyownt wrote: post #224
martinpw wrote: post #165

Earlier quoted context omitted.

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.

This was indeed one of the sources I read to become a git expert. Git is simple and elegant on the inside. Which you'd never believe if you only studied its UI.

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

#244

Post by dbt00 »

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…

If you feel like fucking around with new source control tools, jj (jujutsu)'s megamerge workflow is really good at this.

(If you're not interested, feel free to skip the rest of this).

I have each in process workstream in a commit that is merged at the top level, then I have a new wip commit off of that where stuff I'm typing right now sits.

It's easy to split/squash/absorb parts of that commit into the right destination, but also to introduce parents of the megamerge that will never get merged.

(This is a better/longer writeup of this concept)

https://isaaccorbrey.com/notes/jujutsu-megamerges-for-fun-an...

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

#245

Post by harshreality »

adjejmxbdjdn wrote: post #233
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?

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 ad…

If the dev's working tree isn't exactly what they checked in, how do they build or test the commit? Do they YOLO a partial commit and wait for it to be accepted or rejected by the CI? Isn't that a problem to be solved by improving the CI pipeline?

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

#246

Post by locknitpicker »

BeetleB wrote: post #91
locknitpicker wrote: post #28

Earlier quoted context omitted.

> I also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling. I recall checking Mercurial back in the day and being puzzled by the lack of basic features such as the ability to stash changes. I also recalled that the community was dismissive of the lack of such a basic feature, with comments such as users could always create local branches, of even we could perhaps install a module…

> I recall checking Mercurial back in the day and being puzzled by the lack of basic features such as the ability to stash changes. I also recalled that the community was dismissive of the lack of such a basic feature, with comments such as users could always create local branches, I started with Mercurial, eventually got forced into git, and now use jujutsu. Totally agree with the Mercurial developers: Just use a br…

> Even though I used stash a lot in my git days, I don't miss it at all while using jujutsu. The benefit of jj is the ease with which one makes branches (without needing to name them).

This topic is not about stashing though. It's about UX and providing first-class support for a basic use flow. If git stash was an alias for creating a branch and committing local changes to it, the point still remains: the problem with Mercurial was how it went way out of their way to argue against supporting features that users actually wanted, and supporting it as a first class feature.

And to me that's why ultimately Mercurial was bound to be forgotten while the tool that met uses' needs attained the status of de-facto standard.

The same can be said about other major features such as support for large files.

To top things off, the way that git maintainers have been actively adapting to feedback from jujutsu's users is yet again proof of why git still remains the de facto standard.

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

#247

Post by Arainach »

fooker wrote: post #207
Arainach wrote: post #143

Earlier quoted context omitted.

The bad states Git "allows you to unfuck" are largely caused by Git's awful UX (confusing and multipurpose commands based on inner workings), so Git gets no credit for "solving" a problem it caused.

Not just mistakes though, the power of git is being able to undo anything you do with git. If you’re claiming to have never needed any kind of undo functionality, you probably don’t even need a version control system :)

You can also undo things in Mercurial - there are just fewer footguns to need undoing.

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

#248

Post by fooker »

Arainach wrote: post #247
fooker wrote: post #207

Earlier quoted context omitted.

Not just mistakes though, the power of git is being able to undo anything you do with git. If you’re claiming to have never needed any kind of undo functionality, you probably don’t even need a version control system :)

You can also undo things in Mercurial - there are just fewer footguns to need undoing.

No, it's pretty easy to cause irreversible damage. This is a fairly well known advantage of git over literally everything else.

https://stackoverflow.com/questions/7376915/recover-lost-fil...

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

#249

Post by ezst »

t43562 wrote: post #70

Mercurial was safer and better. I still use it and it's still safer. The bookmarks feature which is supposed to be the solution for short-lived branches is hard to understand though. I'm probably dumb but I can't work it out and hence the overall tool is that much less useful. It needs a github-like website and Heptapod would be great if I could use it - I've set up a project, been unable to do anything and then had…

> The bookmarks feature which is supposed to be the solution for short-lived branches is hard to understand though.

yup, it came up as a response to git and people getting more and more re-wired into thinking of "branches as pointers", with its own bag of implicit state and behaviour. No wonder it felt clunky and unpolished used in this context. That said, it was a pretty effective way to globally distribute a namespace of string→commitID pairs, i.e. a list of commit bookmarks, and at least in that sense the feature wasn't a total misnomer/let-down :-)

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

#250

Post by Arainach »

fooker wrote: post #248
Arainach wrote: post #247

Earlier quoted context omitted.

You can also undo things in Mercurial - there are just fewer footguns to need undoing.

No, it's pretty easy to cause irreversible damage. This is a fairly well known advantage of git over literally everything else. https://stackoverflow.com/questions/7376915/recover-lost-fil...

It's "easy" with a single deprecated command that no one I know of has ever needed. I didn't even know that command existed.
Post reply on HN