sha,message,author_date,committer_date,raw_author,raw_author_label,raw_committer,raw_committer_label,repo,repo_label,author,author_label,committer,committer_label
f8277d0fb9c05a88a9ff01d996e31d55f0f0a645,"sqlite-utils query can now run DML (#120)

* Failing test showing that DML in `sqlite-utils query` doesn't work
* Run `sqlite-utils query` in a transaction so that DML is committed

Thanks, @tsibley!",2020-07-08T05:14:04Z,2020-07-08T05:14:04Z,f25304fb12f6d6fab36f551427610ed8e96f0c2f,Thomas Sibley,cd792325681cbad9f663f2879d8b69f1edbb678f,GitHub,140912432,sqlite-utils,79913,tsibley,19864447,web-flow
ae4593316ccf5e42ad26f27033193834a7e696c8,"Add insert --truncate option

Deletes all rows in the table (if it exists) before inserting new rows.
SQLite doesn't implement a TRUNCATE TABLE statement but does optimize an
unqualified DELETE FROM.

This can be handy if you want to refresh the entire contents of a table
but a) don't have a PK (so can't use --replace), b) don't want the table
to disappear (even briefly) for other connections, and c) have to handle
records that used to exist being deleted.

Ideally the replacement of rows would appear instantaneous to other
connections by putting the DELETE + INSERT in a transaction, but this is
very difficult without breaking other code as the current transaction
handling is inconsistent and non-systematic.  There exists the
possibility for the DELETE to succeed but the INSERT to fail, leaving an
empty table.  This is not much worse, however, than the current
possibility of one chunked INSERT succeeding and being committed while
the next chunked INSERT fails, leaving a partially complete operation.",2020-07-06T21:18:23Z,2020-07-08T17:26:20Z,f2f4d10a554519ea00fb44a5f6377123c59e1f22,Thomas Sibley,13ae486343ea6454a93114c6f558ffea2f2c6874,Simon Willison,140912432,sqlite-utils,79913,tsibley,9599,simonw