What would be nice is to add to this a way to plug language specific semantic analysers. Then it could be possible to do queries like "which commits did changes to a specific function" and so on.
That's in some sense already native git functionality.
(Though I recognize that the entire askgit here is essentially a layer on top of some existing functionality).
But changes to a specific function is a particularly underused feature in git.
You do `git log -L :nameOfFunction:fileItLives.ext` and git will show you changes to the function over time.
Of course that syntax is completely arcane (which contributes to its underuse), but e.g. for Python I just wrote a trivial thing to let me instead write `git pylog foo.bar.baz` and it translates to the right syntax above (that lives here: https://github.com/Julian/dotfiles/blob/76bd63f6c9a2c650c185...)
I have always wondered why GitHub doesn't add such functionality, its a no-brainer how much it would help to have a way to right-click a function and see how has it changed through history, it could use an interface where you scroll through time (eg the most you scroll the older versions you see, until you reach when it was created); same thing for files.
Yeah, I find it of little use due being syntax agnostic (e.g can't tell me about the changes on a function because it doesn't know what a function is). If you are taking about me asking the same for "files" I meant being able to see all the versions of a file in a single page (maybe using "infinite scroll" in case there are too many)
I'm the creator of AskGit - and this is something I've been thinking a bit about, unsure of the best way to implement and very open to ideas! Adding language specific analysis (this line is a comment, this is a function name, etc) is really interesting to me and I think could really kick this tool up a notch (there are still some more fundamental needs I'd like to address though, such as diffs and blames, query performance, etc).
I've been considering leveraging the syntax highlighting implementation in editors to make this possible (rather than something as heavy handed as parsing a "universal" AST, though I know there are projects to do this)...
You are maybe aware of this already then but someone here might like to know that the Fossil DVCS is built on top of SQLite, by the same author (edit as pointed out by Gaelan:) as SQLite.
The VTAB extension is new. The documentation is a bit thin compared to the rest of SQLite. (To be clear: the documentation is good; just not fantastically awesome like the rest of SQLite.)
The main Achille's Heel of VTAB is wrapping your head around the indexing API: the basic idea is you need to tell the query planner which of a set of columns is best to work with. It is exceedingly unintuitive. This is compounded by the problem that the planner essentially refuses to do binary-search queries on more than one column of a VTAB. (Hell -- getting it to use any binary-search on any index is nearly impossible.) The result is that unless you're in a real bind, you should always translate your custom VTAB data into a reified table.
This is all compounded by the fact that the slightest misstep in the callback API will corrupt/confuse/lockup SQLite (the in-memory representation -- your data is still safe). I'm glad VTAB exists, and I know it's just a side-effect of the compression support, but goddamn it's frustrating for it to be almost be awesome...
This is really nice. I experimented converting natural language to git log commands this week (https://twitter.com/danielbigham/status/1294461750251839489), but mapping natural language to git sql might be better and more flexible in some cases.
Actually I think it says a lot about how expressive SQL is.
I get why a lot of developers take swipes at SQL - it is a bit different to other languages. But you cannot beat it for what it does.
Another ‘great’ language is XSLT - so far I’ve seen nothing else that comes close for transforming data. It’s just a shame it’s so closely tied to XML which has understandably fallen out of favour
I’m not sure there’s much truth to your statement. There’s nothing inherently complex about git’s internal data structure nor does putting a SQL interface on something indicate a level of complexity.
