It may be more typing but I can write SQL in my sleep whereas the git CLI I cannot.

Though if I regularly needed the information that this tool retrieves I would probably have memorized the relevant CLI commands by now.

> git branch

Yep. And to list worktrees you use:

    $ git worktree
    error: need a subcommand

Oh woops. But to show all refs instead of just the branches you surely just:

    $ git show-ref
    0003692409f153dd725b3455dfc2e128276cfbe2 refs/branchless/0003692409f153dd725b3455dfc2e128276cfbe2

No. But I can just cut(1) out that SHA1...

These SQL-like commands are probably meant to be familiar and guessable. Not terse. And then you can change the query instead of using all sorts of utility commands in some ad hoc pipeline (or look up whatever switch they threw in to turn on and off things like SHA1 as first column). If you don’t like the latter.

‘select * from branches’ is explicitly and unambiguously going to give me information, not change state. I always feel apprehensive with ‘git branch’ and end up reading the git-branch man page with its 500 options. For an SQL native GQL looks wonderful.

I mean you intentionally chose the most basic of the queries and translated them into different git gui commands.

    SELECT name, COUNT(name) AS commit_num FROM commits GROUP BY name ORDER BY commit_num DESC LIMIT 10

something like that is more complex and less easily gleaned by the git gui. or something else that's dead simple to remember how to do in sql vs probably having to open up the git manpages or cobble some script together to do:

   SELECT name, commit_count FROM branches WHERE commit_count BETWEEN 0 .. 10

I used the examples they provided on the repo README. I would still argue I can get the same results with less typing.

  git shortlog -sn | sort -r | head -n 10

If I run the 2nd command example against the chromium repo, it takes several minutes where a shell script using git for-each-ref takes about 8 seconds. I would also argue that this might be better expressed as commit_count <= 10 but I realize you're also using an example. This is the script I ran:

  git for-each-ref --format='%(refname:short)' refs/heads/ | while read branch; do
    commit_count=$(git rev-list --count $branch)
    [ "$commit_count" -le 10 ] && echo "Branch: $branch, Commit Count: $commit_count"
  done

As weaksauce mention the main goal at this point is not the speed but correctness and support more SQL features, but performance is very important, the next release should be faster by 20% because the migration to gix and after be stable as language and engine features we will work more on optimization

> I used the examples they provided on the repo README.

I was using the more complex examples from their README as well (except added a name to the second one to make it more useful).

> I would still argue I can get the same results with less typing.

so what? we type words and sentences much quicker than having to type control characters like - and |. also, you still have to know the invocations to sort and head off the top of your head without looking them up whereas a simple sql select statement is something most programmers would know how to do in their sleep.

  git for-each-ref --format='%(refname:short)' refs/heads/ | while read branch; do
    commit_count=$(git rev-list --count $branch)
    [ "$commit_count" -le 10 ] && echo "Branch: $branch, Commit Count: $commit_count"
  done

I think we can agree this is much more complicated to write than:

   SELECT name, commit_count FROM branches WHERE commit_count BETWEEN 0 .. 10

> If I run the 2nd command example against the chromium repo, it takes several minutes where a shell script using git for-each-ref takes about 8 seconds. I would also argue that this might be better expressed as commit_count <= 10 but I realize you're also using an example. This is the script I ran:

if speed matters then your script is fine to bang out if you need it but for one off queries that you know to be correct (look at how simple the second query is) it is probably fine and most people aren't working on chromium so speed is probably never going to be an issue in the first place.

This approach falls flat when you start doing analytical queries, and it assumes you already know the git incantations, which most people don't.

The git CLI is notoriously irregular, as can be seen by your examples. Having a clean, regular language to query git objects seems valuable.

Surprised by the variety of answers here. My view on this is that I won't use this on a daily basis. I doubt most will. But I'd love to remember about this when I want to extract a very specific information from git

Sql is a more well known DSL than git CLI

1. SQL is more consistent

2. SQL is more capable

3. SQL is more well-known

At least the SQL-like syntax is more consistent. It might be easier to figure out how to make any given query starting from the SQL “schema”.

The Goal is to provide most of the SQL features so if one query can replaced by command we should support it so user is free to choice any tool also to do filter on git branch you need to get it in format and use grep on linux but it's very easy for most developer to filter with SQL language

It reduces the amount to learn. If you know SQL you need to remember the command to list the tables and describe them. Then you are productive.

In addition SQL is a powerful functional programming language with joins! So that is handy too.

The existence of this GQL is yet another example showing the failure of the unix model, where programs output text instead of structured data. Now we need a new query language and a new external adapter program just to do a basic select. Yet we call it progress.

Imagine instead if there was a standard xQL that could run on any tool.