Commit Graph

50 Commits

Author SHA1 Message Date
Fintan Halpenny f0390e00d9
cli: print success to console on `rad issue state`
Indicate that the `rad issue state` operation was successful to the
user by printing a message to the console.

Solves:

    rad issue show 71020de8478b15b3f7a619f2f93d3cfb8771cde2
2025-01-14 13:41:13 +01:00
Fintan Halpenny 7ddb1119a5
cli: show revision on rad patch checkout
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
2024-03-11 11:56:11 +01:00
cloudhead 17744a03fd
cob: Properly authorize root actions
Previously, authorization was only checked for ops after the root op.
We also avoid creating empty actions for `assign` and `label`, which
was needed for non-authorized users to be able to create issues/patches.
2024-02-23 12:31:13 +01:00
cloudhead 9767b485c2
cli: Improve `rad inbox` output
* Add change authors
* Add object status
* Add colors
2024-02-12 14:03:14 +01:00
cloudhead fe55de181d
cli: Add new `rad inbox` command
Shows you updates on local repositories.

Included here is a basic implementation of a notification system. A new
database is created and updated after every fetch, with refs that have
changed.

The `rad inbox` command can then list items in the database and delete
them.
2024-02-06 11:40:58 +01:00
cloudhead a46bcb2247
cob: Distinguish between commit parents
Previously, COB change commits would not distinguish between their
parents. This means that they would try to load source code commits
(eg. for patch COBs) and then fail since those commits wouldn't have a
manifest or `Rad-Resource`.

We introduce a backwards compatible change here which is that parent
oids that are not COB commits are accompanied by a commit trailer called
`Rad-Related`. This is for all related content that should be pulled in
but is not part of the change graph proper.

When building the change graph, we simply ignore commits that are marked
as "related".
2024-01-22 21:20:01 +01:00
Fintan Halpenny 498da296fd
cli: show head on patch opened
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
2024-01-10 15:51:09 +01:00
Fintan Halpenny a8cca57c0a
cli: inline patch revision updates
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
2024-01-09 13:06:03 +01:00
cloudhead 6349c1c559
cli: Small change to output for clarity
So that users don't confuse the revision id with a commit id, we
explicitly state it's a new revision id.
2024-01-08 17:46:22 +01:00
cloudhead e4f06e9c9d
cli: Improve `rad remote add`
By default, this command now:
* Follows the peer if not already followed
* Syncs refs of the peer, if it wasn't followed before
* Fetches refs into working copy

This functionality can be disabled via `--no-sync` and `--no-fetch`.
2024-01-08 17:28:01 +01:00
cloudhead 7169e97bd5
cli: Tell the user when canonical head is updated
This is useful especially in multi-delegate repos, since patches can be
merged without the head being updated.
2024-01-05 12:09:30 +01:00
cloudhead 9ada30255b
cli: Don't sync on git-fetch
It's actually not such a great idea to sync on git-fetch and
git-ls-remote, as syncing is supposed to happen in the background
already, and if you want to force a sync, you can just call `rad sync`.

Previously, it would be annoying that when you called `rad sync` and
then `git fetch`, it would still attempt another sync, for example.

Moving forwards, it might make sense to call `git-fetch` on `rad sync`
(so the other way around), because `git-fetch` is free (it doesn't talk
to peers), and you almost always want your working copy up to date with
your storage.
2023-12-13 14:47:14 +01:00
cloudhead d773659d66
cli: Don't fork on clone
Since forking creates your `rad/sigrefs`, which then needs to be backed
up forever, we avoid forking on `rad clone`. This should make little or
no difference for users, as the "fork" will be created on `git push`.
2023-12-13 12:14:06 +01:00
cloudhead 4605348d68
cli: From "tracking" to "seeding" and "following"
Split the commands and change the naming.

* Tracking a repo is now called "seeding"
* Tracking a peer is now called "following"

In this commit, we don't change most of the internal code, only the
user-facing part.
2023-12-06 09:56:57 +01:00
Fintan Halpenny 82a53e3a53
radicle: UserInfo for Repository::create
The fetch V2 improvements introduced a `UserInfo` type that is used to
set the Git config's name and email when cloning a repository. This
`UserInfo` can also be used when creating a new `Repository`.

The `Storage` type now takes a `UserInfo` so that it can be passed to
`Repository::create`, for creating a new repository.

For testing, this requires adding a new `fixtures::user` so that
testing `Storage` instances can be easily constructed.

It also means that the `radicle-cli` tests all changed with new SHAs
since the name and email are used as part of the hashing input.

N.b. the order of the timelines while testing the identity cob
changed. It's not clear why that is.

Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
2023-11-09 16:43:34 +01:00
Fintan Halpenny ea7f26dbdf
radicle: wire up radicle-fetch
Wire up the `radicle-fetch` crate to the fetch logic in the
`radicle-node` worker.

Any required traits for storage, identity, tracking, and transport
used by `radicle-fetch`.

The worker adds a new module to run the `git upload-pack` process and
pipes the `stdout`/`stdin` to the respective channels.

The `Worker` type required adding a `FetchConfig` to easily allow the
configuration of fetches and passing the signer and tracking store
location through to the fetch `Handle`.

The channels code is adapted to have a new writer that always flushes
when a call to `write_all` is made. This is necessary since the
Gitoxide code never calls `flush`, and so it will hang since no data
is sent until `flush` is called.

Since `UserInfo` is used to set up a newly cloned repository, this
changed some of the SHA1 hashes output in the CLI test examples. It
was also necessary to update the CLI's clone code to be deterministic
in its output for tests.

Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
2023-11-06 12:06:13 +01:00
Fintan Halpenny 2584ecdb0a
radicle: Pin timestamp for testing
When testing the CLI, "since"-calculations will result in different
values over time:

    now
    1 month ago
    2 months ago
    10 months ago
    1 year ago
    10 years ago

Initially, the solution was to use the wildcard match from `snapbox`,
`[..]`, to match on these values. However, since these values change
in length it means that they will affect the width of the tables
produced by the CLI.

To ensure the width is stable across runs over time it's possible to
use a time that is the same as the commit time used at testing.

To do this the `Timestamp` type is now a newtype which has a
constructor `now` which will use the `RAD_COMMIT_TIME` env variable
for construction, if it's available and in debug mode. This ensure
that all "since"-calculations will result in `now`.

Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
2023-10-30 14:48:38 +01:00
cloudhead 1d167581f2
cob: Introduce `xyz.radicle.id` COB
Introduces a new COB type to store repository identity documents.

The reason for this change is to:

1. Simplify the code, as the identity document logic resembled a COB,
   yet it had custom logic. This allows existing COB code to be used for
   identities.
2. Make identity document update logic more flexible, since COB actions
   can be added in the future.
3. Re-purpose existing tools around COBs to work on identities, eg. `rad
   cob`.
4. Unify the concept of an identity change proposal, with regular identity
   changes. This means we can remove the `id.proposal` COB in favor of
   using the `id` COB itself.

Notes
-----

* Each repository has one Identity COB.
* The `Proposal` COB has been repurposed into the `Identity` COB.
* Identity documents are stored as *embeds* inside the Identity COB
  actions.
* The action that contains new document versions is called `revision`,
  just like the Patches COB.
* The namespaced `rad/id` ref is a symbolic reference to that Identity
  COB.
* The canonical `rad/id` ref is a direct reference to the commit in the
  Identity COB that contains the latest *accepted* revision of the
  document.
* All commands for managing identities have been folded into `rad id`.
  Hence `rad delegate` and `rad edit` are removed.
* The concept of "rebasing" an identity document is gone.
* The `rad id` output has been updated to match the style of other
  commands.
* When a revision has enough signatures, it is automatically adopted as
  the current identity, there is no longer the need for a "commit"
  action.
* When an identity revision is proposed, and the current identity has a
  threshold of `1`, that identity is automatically accepted due to the
  above point.
* The idea of "verifying a peer's identity branch" no longer applies, as
  COBs cannot be verified one history at a time.
* Since the root commit of the Identity COB does not have a "Resource"
  to point to (it would have to point to itself, which is impossible),
  we've made the resource id optional for COBs.
2023-10-12 17:32:33 +02:00
cloudhead b482ae85f0
remote-helper: Run sync on `git-fetch`
Changes the behavior of `git fetch` by running a radicle network-level
fetch (ie. `rad sync --fetch`) before fetching refs from storage. This
avoids having to run `rad sync` before `git fetch`; and tries to make
sure that refs are always fresh.
2023-09-27 12:29:46 +02:00
cloudhead c94bd50666
cob: Better distinguish patch revisions
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.
2023-09-21 13:51:55 +02:00
cloudhead 5078396028
cli: Move commenting to patch/issue commands
Instead of having `rad comment`, move the command to the respect COBs,
ie. `rad issue comment` and `rad patch comment`.
2023-09-19 14:33:40 +02:00
cloudhead 6c5cba3ca6
cli: Improve patch and issue outputs
* Add author to `issue show`
* Improve author display with alias
* Fix consistency issues when printing authors
2023-09-01 12:26:43 +02:00
Alexis Sellier 3bd5589b1a
cob: Stabilize formats
> I'm going to be making a set of breaking changes to COBs in order to
stabilize the data formats. This is hopefully a one-time change that
bundles various breaking changes.

All COBs have been reworked: issue, patch, id.

The changes included are:

* Revise the assign and tag actions to take a single list of
  assignees/tags to set, instead of an "add" and a "remove" list. This
  makes API usage simpler when editing issues, and simplifies the apply
  function
* Rename "tags" to "labels", and the tag action to label. This is
  because tag is confusing in the context of git, as it could mean a git
  tag. Using label removes that confusion.
* Use DIDs instead of PublicKeys for assignees -- this is more
  future-proof
* Modify the manifest file format in the COB tree. Mainly, remove the
  `history_type` key which is redundant, and use camelCase for keys
* Flatten the `Thread` actions into the parent action type
* Ensure that operations on redacted objects do not fail, since
  redactions could have happened concurrently
* Use a consistent naming scheme for actions, using `.` as separator
* Consolidate comment types and remove `CodeComment`, by adding an
  optional `location` field to `Comment`
* Add many placeholder actions that are not yet implemented

To preserve backwards compatibility, a `legacy` module is created with
the old `apply` function. When loading the manifest, we check whether it
is a legacy COB or a "stable" COB, and in the legacy case, use the
legacy code to materialize the state and then convert the object into
the stable type. Eventually, we'll delete the legacy code.
2023-08-07 11:05:14 +02:00
Alexis Sellier eb701be033
node: Make node aliases required
This is a fairly substantial change, which adds a new configuration file
to the user's `$RAD_HOME` that includes node configuration, including
the alias, and also makes node aliases required.

When running `rad auth`, the user is now prompted for an alias, which
defaults to `$USER`.

When running `rad self`, the alias is now shown.

If the user runs radicle without a config file, the defaults are loaded,
and `$USER` is used as the alias.
2023-07-11 18:08:59 +02:00
xphoniex 37847d4c63
cli: Use `.aliases()` store for patches
Signed-off-by: xphoniex <dj.2dixx@gmail.com>
2023-07-10 16:36:15 +02:00
Alexis Sellier b25c2e452b
cli: Setup tracking branch on `rad patch checkout`
Just like when opening a new patch, we setup a tracking branch on patch
checkout, so that patches can be updated via a push.
2023-06-21 17:01:56 +02:00
Alexis Sellier ec064891cd
cli: Setup tracking branch on `rad remote add` 2023-06-13 11:09:42 +02:00
Alexis Sellier e9ef0f4aa4
cli: Consolidate working copy remote setup
We consolidate the setup done by `rad checkout`, `rad clone` and `rad
remote add`, so that they all check for node aliases, and are all
capable of setting up tracking branches etc.
2023-06-13 11:09:42 +02:00
Alexis Sellier 3d803b2498
cli: Remove `rad patch open`
Remove this command in favor of the `git push` flow.

We also remove the `rad/patches` remote configuration which wasn't
working properly with `git fetch --all`.
2023-06-07 15:57:11 +02:00
Alexis Sellier ac60069a33
cob: Remove `description` from `Patch`
Since patches always have a "root" revision, use that revision's description
as the patch description.
2023-05-26 10:31:00 +02:00
Alexis Sellier 8e89976937
cli: Verify merge, remove `rad merge` command
When applying a `Merge` action, we verify that the commit is in the
history of the default branch of that user.

Since this is not the case when issuing a `rad merge`, and since that
command is no longer needed with the push-based merge, we remove the
`rad merge` command completely.
2023-05-23 16:11:42 +02:00
xphoniex 95e3b9673d
cli: Show alias on `rad issue` and `rad patch`
Signed-off-by: xphoniex <dj.2dixx@gmail.com>
2023-05-22 15:13:28 +02:00
Alexis Sellier 103ee4e23d
cli: Show commit listing in `rad patch show` 2023-05-12 12:43:44 +02:00
Alexis Sellier fd1237b2db
cli: Use `git push` to open or update patches
This adds the ability to the git-remote-helper to open and update
patches via a `git push` to the magic ref `refs/patches` and
`refs/heads/patches/<patch-id>`.

The main change is that we had to move away from offering the `connect`
capability in the remote helper, to offering `push` and `fetch`
individually.

To get a feel for how this works, see the `rad-patch-via-push.md`
example.
2023-05-12 12:22:08 +02:00
Alexis Sellier 649d59f143
cob: Include head in initial patch entry in DAG
This change ensures that we include as a parent to the initial commit
of a patch COB, the head of the branch we are proposing as a patch.

This was already happening for patch updates, but we forgot to also
include it for the initial patch revision.

This ensures that the code is always fetched alongside the patch.
2023-05-02 09:18:17 +02:00
Alexis Sellier 3b20d45d80
cli: Display patches like issues, in `rad patch`
We also make sure not to bail if one of the patches fails to load.
2023-04-26 12:29:32 +02:00
Alexis Sellier 7a08a1d459
cli: Get fetch after track working
When tracking a repository with the `--fetch` option, we run a fetch
once the tracking is done.

When tracking nodes, we don't accept the `--fetch` flag, as there may
not be a repository to fetch.
2023-04-26 09:49:37 +02:00
Alexis Sellier 6346931ce2
cli: Add canonical remote to `init` and `checkout`
Add a remote that points to the canonical upstream.
2023-04-24 15:42:00 +02:00
Alexis Sellier d6cebf613f
cli: Remove `rad fetch` command
The command is replaced with `rad sync --fetch`. Soon, it will be called
from the git-remote-helper, so users won't have to call it explicitly.
2023-04-24 14:19:31 +02:00
Alexis Sellier a285943166
cli: Remove `rad push` command
Users should use `git push` or `git push rad` instead.
2023-04-24 14:19:24 +02:00
Alexis Sellier 442e8a7128
cli: Cleanup patch examples a little 2023-04-22 13:59:18 +02:00
Slack Coder 11d10b4e47
cli-test: Support '[..]'s which preserve spacing
By mapping all '[.. ]'s  with any number of spaces inside them into
'[..]'s, examples can preserve text formatting while using this glob
pattern.

The downside is failed output will show '[..]' in place of the original
version with spaces.
2023-04-20 16:52:20 +02:00
Alexis Sellier eecea67ffd
cob: Deduplicate change parents 2023-04-14 13:54:27 +02:00
Alexis Sellier 97f076e3cf
Include dependencies for certain COB actions
We ensure that for example, the given commits are fetched before the
revision or merge actions in a patch.
2023-04-14 13:22:10 +02:00
Alexis Sellier 33461e4be1
Set patch status to `merged` automatically
When a merge is applied to a patch, we check whether the threshold
of delegates has been reached, at which point we set the patch status
to `merged`.

This requires threading the identity document oid through the "apply"
process.
2023-04-05 10:32:45 +02:00
Alexis Sellier b6fa4a4b2a
cli: Some improvements to `rad merge` 2023-04-03 16:06:24 +02:00
Slack Coder 0b7f169c8b
cli: Support revision id in `rad merge`
Revision IDs are globally unique.  Users will be able to use the
Revision ID in place of its patch ID.

Make `rad merge` refuse to merge an older revision unless the `--force`
option is given.
2023-03-31 17:24:55 +02:00
Alexis Sellier 8dba01d6ae
cli: Improve patch command output
* Fix timeline ordering
* Remove spinner noise
* Add revisions to timeline
2023-03-24 13:04:52 +01:00
Alexis Sellier db8ec5735f
cli: Use new widgets for `patch list` 2023-03-21 12:43:44 +01:00
Slack Coder b6c1560a0a
cli: add workflow example with two peers
Make the documentation more realistic by using two peers, a maintainer
and a contributor, for the client examples.  Define them as 'workflow'
examples, ordering them in their own directory to aid user navigation.
2023-03-20 18:27:58 +01:00