When running `rad patch list`, show the set of delegate reviews for
each patch, with the following meaning for the symbols:
- ✔: delegate has accepted the patch
- ✗: delegate has rejected the patch
- -: delegate has not made a verdict on the patch
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Help the user know which revision they currently have checked out when
running `rad patch checkout`.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
In order to bootstrap the COB cache, and also in case of issues,
supply a command for caching a set of patches/issues, or a single
patch/issue.
This is necessary since reads are not read-thru, it may appear that
COBs are missing when in fact they haven't been cached when first
moving over to the cache.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Implement caching for the `Issue` and `Patch` COB. This is achieved by
having the `Transaction::initial` and `Transaction::commit` methods
take a cache which can update the newly created/updated object. The
`Store::remove` method also takes the cache for removing the object
from the cache, as well as the repository.
This meant that the `*Mut` types for the respective COBs are required
to carry a cache alongside the repository store. Identities will not
be cached, and so this is always set to `NoCache` -- which performs no
caching, and always succeeds.
To perform cache reading for issues and patches, the `cache::Issues`
and `cache::Patches` traits are introduced. They capture the minimal
amount of methods that are needed for the `rad issue` and `rad patch`
CLI commands.
The implementor for each of these traits is there respective `Cache`
types, which combines their backing repository store and the SQLite
database. They both provide convenience methods:
- `create` (and `draft` for patches)
- `get_mut`
- `remove`
which can be used instead of their repository store counterparts.
All uses of the repository stores (where needed) are replaced with
`Cache` types.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
We were using the two pretty interchangeably. "Project" should only be
used to refer to the repository payload. "Repository" should be used
when referring to the resource that is fetched, synced, cloned, checked
out etc.
Previously, the head of the opened patch would not be displayed, and
so the user could not tell what it was if any updates were applied.
Show the head for the opened revision. The below shows the difference
between before and after, respectively:
```
├─────────────────────────────────────────────────────────────────────┤
│ ● opened by z6MknSL…StBU8Vi (you) now │
│ ↑ updated to 8d6692ce2b2219a54d09ccd5feefedb2bae33eba (02bef3f) now │
│ ↑ updated to 8438ab3940316abe65c93982a0a8f39688400359 (9304dbc) now │
╰─────────────────────────────────────────────────────────────────────╯
```
```
├─────────────────────────────────────────────────────────────────────┤
│ ● opened by z6MknSL…StBU8Vi (you) (8b0ea80) now │
│ ↑ updated to 8d6692ce2b2219a54d09ccd5feefedb2bae33eba (02bef3f) now │
│ ↑ updated to 8438ab3940316abe65c93982a0a8f39688400359 (9304dbc) now │
╰─────────────────────────────────────────────────────────────────────╯
```
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Allow `rad patch edit` to take a `--revision` option which will edit
the description of the specified revision, rather than the root
revision.
If the flag is not specified, then the original behaviour of editing
the root revision's title and description is used.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Instead of having a timeline of a patch be global and sorted by
timestamp, organise it via revisions. Each revision has an entry in
the timeline, sorted by timestamp. Under each revision, a series of
updates are inlined, also sorted by their timestamps. Currently, these
updates can either be reviews or merges.
For example:
```
├────────────────────────────────────────────────────────────────────────────┤
│ ● opened by fintohaps (you) 1 week ago │
│ └── ✓ accepted by fintohaps (you) 1 week ago │
│ ↑ updated to 5f2a123e3f2aa60f2e03815df283563495b73085 (a1c3c0f) 1 week ago │
│ └── ✓ accepted by fintohaps (you) 1 week ago │
│ └── ✓ merged by cloudhead (z6Mkt67…v4N1tRk) now │
╰────────────────────────────────────────────────────────────────────────────╯
```
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
It's useful to be able to print out the Rust data of a Radicle defined
COB for debugging purposes, since the current CLI commands will only
show a subset of the data.
Add `--debug` flags to `rad patch show` and `rad issue show` that
print the data to stdout.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Prevent `rad patch update` to create an identical revision to any
other revision in the patch, rather than just the latest revision.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Shell out to `git`, avoiding using `git2`. This is to avoid an
issue where somewhere within the fetch there is an attempt to lookup a
`rad/sigrefs` object, which says that the object is missing. It is
suspected that this is due to the object being localised in the same
packfile as other objects we are fetching. Since the `rad/sigrefs`
object is never needed nor used in the working copy, this will always
result in the object missing. This seems to only be an issue with
`libgit2`/`git2` and not `git` itself.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Allow the CLI user to update a patch's base commit through the `rad
patch update` command.
There was check to see if the head of the branch was the same as the
head of the revision, which would result in the update being skipped.
This was adapted to check that the head *and* the base were the same.
A test was added in the examples to showcase this use.
Signed-off-by: Fintan Halpenny <Fintan Halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
It is more natural for the review command to exist as a subcommand of
patch, since the reviews are for patches.
Remove the `rad review` command, moving its functionality to the `rad
patch` command. The rad-patch.md and rad-review-by-hunk.md tests are
modified to use the `rad patch review` command.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Rename the --remove options to --delete for assign and label, to be
more consistent with review, and let this be the standard.
Clean up any typos around labels/dids and issues/patches.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Make the CLI easier by unifying the label and unlabel, using `--add`
and `--remove` options instead.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
It is more natural for the assign and unassign commands to exist as
subcommands of the object they are assigning to, i.e. issues and
patches.
Remove the rad assign and rad unassign commands, moving their
functionality to the rad issue and rad patch commands. The
rad-issue.md and rad-patch.md tests are modified to include a assign
test.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
It is more natural for the label and unlabel commands to exist as
subcommands of the object they are labelling, i.e. issues and
patches.
Remove the `rad label` and `rad unlabel` commands, moving their
functionality to the `rad issue` and `rad patch` commands. The
`rad-issue.md` and `rad-patch.md` tests are modified to include a
label test.
The `rad patch show` command did not support showing labels as part of
its output. This was also included to confirm the test above was working.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
My use case for this is to have a script that lists my outstanding
patches so I can ping people for review or merge if there's no
movement for a long time.
Signed-off-by: Lars Wirzenius <liw@liw.fi>
Add the `--revision` option for `rad patch checkout`. This allows the
user to specify a particular revision of the patch to checkout. If the
revision is not specified it will use the latest revision of the patch.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Add the `--name` option to `rad patch checkout`. This allows the user
to name the branch they are checking out, rather than use the
`patch/<short-id>` format.
This change includes returning early for setting the upstream branch,
if the upstream already existed.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Add a `--force` flag to forcibly checkout the branch to the latest
revision, if the branch already exists.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Make the validation logic customisable by extracting it out into a
separate trait that can be defined by other crates.
The Repository validation logic stays the same.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
The `rad patch checkout` command would blindly create a branch when
being executed. If there was a branch already existing and user had
committed to that branch, switched without updating the patch, and
then switched back, then they would lose the commit on that branch --
the original commit of the patch would be taken instead.
Fix this by first checking if the branch existed beforehand, and
setting the workspace to use that branch's commit.
Add a test to ensure that this works as expected.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
The `Patch` API and semantics are changed a little bit:
* It's now valid again to propose a revision without being the patch
author.
* To get revisions by the patch author, `Patch::updates` is used.
* `Patch::latest` now only looks at revisions by the patch author.
* Added `Patch::revisions_by`, `Patch::authors` and `Patch::latest_by`.
* The merge behavior on git-push is improved to favor revisions that
merge more recent commits. We also allow for merging the non-latest
revision.
Sets the current branch's upstream to point to the given patch.
This allows for pushes to update the patch.
When opening a patch, if the current branch already has an upstream,
it isn't updated automatically. This is why this command exists.
Instead of having two types, we simply have one, called `Entry`, which
we rename from `Change`.
There was no real benefit to having two almost identical types, but lots
of added complexity. This patch simplifies the crate by removing one of
the types.
Sebastian Martinez
cloudhead
Fintan Halpenny
Fintan Halpenny
Lars Wirzenius