4 ms·

I like the idea, and I like sql, but I feel like this is a lot more typing for the same information you could extract using just git commands. Am I missing some

I like the idea, and I like sql, but I feel like this is a lot more typing for the same information you could extract using just git commands. Am I missing something? Take for instance: The commit example: select name, count(name), from commits group by name is actually: git shortlog -sn The tag example: select * from tags is actually: git tag The branch example: select * from branches is actually: git branch

snordgren 3y ago
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.
umvi 3y ago
Sql is a more well known DSL than git CLI
dtgriscom 3y ago
The git CLI is notoriously irregular, as can be seen by your examples. Having a clean, regular language to query git objects seems valuable.
esafak 3y ago
This approach falls flat when you start doing analytical queries, and it assumes you already know the git incantations, which most people don't.
joshuanapoli 3y ago
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”.
paulddraper 3y ago
1. SQL is more consistent 2. SQL is more capable 3. SQL is more well-known
willtemperley 3y ago
‘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.
avgcorrection 3y ago
> 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.
quickthrower2 3y ago
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.
deleted 3y ago
[deleted]
weaksauce 3y ago
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
- bastardoperator 3y ago
  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
  - weaksauce 3y ago
    > 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.
michaelsalim 3y ago
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
Too 3y ago
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.
amrdeveloper 3y ago
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

snordgren 3y ago

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.

umvi 3y ago

Sql is a more well known DSL than git CLI

dtgriscom 3y ago

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

esafak 3y ago

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

joshuanapoli 3y ago

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

paulddraper 3y ago

1. SQL is more consistent 2. SQL is more capable 3. SQL is more well-known

willtemperley 3y ago

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

avgcorrection 3y ago

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

quickthrower2 3y ago

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.

deleted 3y ago

[deleted]

weaksauce 3y ago

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

bastardoperator 3y ago
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
- weaksauce 3y ago
  > 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.

michaelsalim 3y ago

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

Too 3y ago

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.

amrdeveloper 3y ago

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