Hacker News new | ask | show | jobs
by rubyist5eva 1240 days ago
Mercurial's branch management makes more sense. If you want to know which branch a commit originated from in git, good luck.

Many things in git, are frankly anti-patterns in any other sane versioning system - comitting partial changesets because of the index? gross. Rewriting history and force pushing? absolutely insane.

The fact that I don't have to "grok" mercurial like you need to git is actually a plus. Mercurial can do everything that git does (and more: check out changeset evolution in mercurial, it blows anything you can do with git rebase out of the water) and it doesn't require Ph.D. level knowledge in directed acyclic graphs to do it either.
1 comments
WorldMaker 1240 days ago
> Mercurial's branch management makes more sense. If you want to know which branch a commit originated from in git, good luck.

`git merge --no-ff former-branch` by default includes "former-branch" in the auto-generated merge commit name. When it matters what branch a commit "originated" on, it's very easy to use `--no-ff` (which doesn't rewrite history and won't need any sort of force push!) and most PR tools used to default to that before "rebase" and "squash merge" became some people's favorites because of some weird (in some cases OCD) wish to see SVN-like straight lines only in their commit history.

link
howinteresting 1240 days ago
It isn't a "weird ... wish", a linear history is the correct default. Merges have always been, and should continue to be, a tool of last resort. In general it is good to minimize complexity in life.
link
WorldMaker 1240 days ago
Merges are the default state of life in any source control system with more than one person or machine involved. They are a regular, required need. Sweeping them under the rug, pretending that they don't happen, acting like they are rare is exactly the sorts of things that added complexity to systems such as CVS, SVN, TFS, Perforce and much more. It is exactly what adds complexity to so many of these rebase-only and squash-only workflows people like to constantly post about using in git.

Linear history is a punchline that ignores the reality of source control. The only truly "linear" history I'm aware of in source control is systems built on patch theory/operational transforms/CRDTs and that form of linear is subject to reordering and still needs explicit merge commits with (implicit) multi-commit dependencies even if there are few stated needs to visualize that as a DAG.

I agree with you, in general it is good to minimize complexity in life, which I why I eliminate rebase workflows and squash merges from mine. I prefer to see the evidence of where merges happened (and they should happen early and often), and graph data structures are very familiar to me as a software developer, including traversing them. (And git offers useful traversal tools such as --first-parent for when you want to view the DAG more like a linear history and ignore some of the noise. There's no reason to artificially simplify the DAG when DAG traversal is easy and accurate.)

link