| Age | Commit message (Collapse) | Author |
|---|
|
|
|
It's more convenient to have the "..." here because all of the
code-review commands use `get_merge_base`. Otherwise I'd end up having
to add it to most of the other commands.
But now, instead of only adding it to the default merge base, add it to
all merge bases, including the one set by `code-review-start`. This
makes all merge bases consistent, and means you don't have to include
the dots when setting a custom merge base.
|
|
I was inspired by Jake Zimmerman's blog post "Code Review from the
Command Line" (https://blog.jez.io/cli-code-review/) to add an
environment variable override for the merge base. This allows us to set
a different merge base for individual command executions.
|
|
I don't think this is the right approach, but since I added the "..." in
`code-review-changed-files` in 7659cf07f118fec4c1ba9677c82a7ef61511e797,
removing the "..." from here allows the difftool script to work when
using the default merge base.
|
|
Add the range filter to try to remove commits that we don't care about.
Still not sure if this will work in all cases, as sometimes `..` seemed
to give me the right collection of files and sometimes `...` did.
code-review-difftool:
Pass the merge base without range dots (`..` or `...`) to Vim Fugitive,
as it doesn't accept revisions with ranges. Not sure what to do if I get
a range with two revision names yet, though.
Turns on Bash's `extglob` in order to use `?(...)` to include both
patterns in the expansion.
|
|
If the database doesn't exist, we get this error:
Error: near line 3: no such table: merge_bases
This is because `sqlite3` will always create a new database if it
doesn't exist when running a command against a database. The
newly-created database doesn't have the required table, and we get the
error.
Fix the problem by ensuring the database always exists and is
initialised properly.
|
|
This was taken care of in 21534162124501f0410ee31cd31130aa3b92a9f3.
|
|
|
|
Don't duplicate rows if we call `create_merge_base` multiple times.
Doing so would mean we'd get multiple merge base rows for the same head.
Instead, overwrite the existing merge base for a given head using an
upsert.
Thanks a bunch to MarqueIV
(https://stackoverflow.com/users/168179/marqueiv) on Stack Overflow for
demonstrating a way to do an upsert without the UPSERT syntax. This
enables us to do an upsert on SQLite < 3.24.0. Neat trick.
https://stackoverflow.com/questions/15277373/sqlite-upsert-update-or-insert/38463024#38463024
|
|
Put these functions in a function-only file that can be sourced by other
scripts that need database access.
|
