Hacker News Reader

Comment by masklinn | Hacker News Reader

Mercurial has a somewhat similar concept predating this (added circa 2010): revision sets (https://www.selenic.com/mercurial/hg.1.html#revsets) (for selection, and templates for selection but git has that built-in, kind-of, via log --format)

View on HN

Mercurial's are completely general, though. Any Mercurial command that can accept a revision as an argument can also accept a revset expression. And templating isn't just for log, but for many other commands, such as grep or annotate (blame), and it's the same templating language for all of them. I also find hg templates a bit easier to read, because they're Djangoish/Jinjaish instead of being printf-ish like git's. Plus, you can save and compose Mercurial templates and revsets.

I was actually hoping that gitql had finally gotten inspiration from Mercurial and git would grow a general purpose query language, but it's read-only. :-(

Revsets are a wonderful feature, and it's something I wish git had. Just being able to say I want to see what has changed between this branch head and its latest common ancestor with trunk is an incredibly simple and useful thing to be able to do.

Complete guess based on [1], but wouldn't

  git diff HEAD $(git merge-base HEAD master)

work?

[1]: https://stackoverflow.com/questions/1549146/find-common-ance...

In this case git can do the same thing, but notice you can only do it because git provides a special command for getting that revision. Recasts are really general (a greatest common ancestor function is provided, but can be easily synthesised from more primitive building blocks) and can be used everywhere, so you can bisect over changes you made that touched files matching a pattern, or whatever. They aren't something I use every day, but they are really useful on occasions and allow for some pretty robust tooling to be written.

This requires using bash. I find it kind of cheating that git ships bash on Windows so that Windows users can rely on bash for composing git commands. I'm not sure if Windows users are generally that happy about typing bash commands, but I guess nobody really cares what you have to type in as long as it's high in the Google hits for whatever operation you want to perform.

Mercurial's API (i.e. the CLI) makes a point of being usable with powershell and cmd.exe, which I think some Windows users appreciate.

Another way to look at this is that hg needed to bake this into their core, whereas git didn't need to. There is a non-zero cost to all additional code, so leaning on the shell to do work is generally a smart move.

Git ships with Git Bash on Windows.

Beauty of revsets is their ubiquity.

Diff would be `hg diff -r 'ancestor(default, experiment)' -r experiment`

Want to list commits in experiment? Just change diff to log. Generate patch file with all commits? Change it to export.

You can do that! "master..experiment" means "all commits reachable by experiment that aren’t reachable by master" https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection

I believe the goal is to get a diff, not a list of commits, in which case you need to figure out an expression for getting the last commit common to master and experiment so you can diff it with experiment.

`git diff master..experiment`

I just tried that, and it seems to be the same as `git diff master experiment`. We don't want to diff the two heads. The command in Mercurial is `hg diff -r 'ancestor(master, experiment)' -r experiment`. Comrade trolor seems to have found the correct git expression.

Try

    git diff master...experiment

(note there's three periods)

That works. Can you explain why? Does diff see this as a single commit or as set of commits? If it sees it as a set, how does it decide what two commits to diff from that set? If it's just one, what does it decide to diff?

I'm kind of confused because gitrevisions(7) says the triple dot is symmetric difference, but exchanging master and experiment does not produce the same output from diff.

Not so helpfully it has a different meaning in 'git diff' than in 'git log'. Basically, it means the difference in the second branch from the first common ancestor of the two branches.

True all the way, but that may be a bit too much to chew on for people whose mind is already blown by gitql.

Reply on news.ycombinator.com