> 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.
Remove most of the user-friendly functionality and simplify this command
so that it is only used for scripting.
`git push rad` is now the proper way of updating patches.
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`.
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.
Instead of `Node::announce_refs`, we call `rad sync` to have the
terminal block while waiting for nodes to fetch the changes.
We also change the use of `git push` in the patch command to not
trigger syncing in that case.
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.
* Properly remove review help message from review
* Remove `--no-confirm` and confirmation step
The CLI should be mostly non-interactive for day-to-day commands,
keeping the interactivity for the TUI.
This commit allows any git revision to be used instead
of the full SHA-1, when specifying COBs.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
We implement a new `Element` trait which allows for more complex output
to be drawn, such as vertical and horizontal stacks.
We adapt `Table` to work within this system.
We refresh the output of `rad patch show` to use these new tools.
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.
Correct assumptions made about how patching work in `rad patch`. Make
the default Patch target a `git ref` in place of a target 'peer'.
Use the canonical head as the git reference. This is head of the
project's master branch which project delegates have concensus on.
By introducing a small limitation: only allowing entries in the change
graph to be addressable, instead of individual operations; we
drastically simplify the CRDT implementation.
There are four advantages:
1. Op ids are just regular SHA-1s
2. There's no need for relative IDs, ops never refer to other ops within the
same commit
3. There's no need for a nonce, since commits can't collide, and neither can op IDs
4. `OpId` can just be an alias of `EntryId`
The disadvantage of course, is that we have to be mindful of how we
create op transactions, since each transaction creates an addressable
unit. For example, we must not include multiple patch revisions in the
same transaction.
It's fairly easy for a user to (by mistake or intentionally) create two
operations with the same OpId. This patch makes it much less likely,
and ensures that if the OpId is equal, it's because the operations
are identical.
Improvements to the CLI output as well as converging towards
`termion` as a backend.
The crates we were using for prompting and spinners were based on
a terminal backend called `console`, which is not really used
anywhere else. There were also limitations in terms of the output
of these crates.
Therefore, we switched to the `inquire` crate for prompting, using
the `termion` backend, which is very standard.
Additionally, we simplify the terminal output to use symbols:
! for Warning
✓ for Success
✗ for Error
... Instead of a mix of words and symbols.
We also include a modified version of the `yansi` crate which plays
well with our table formatting functions by automatically truncating
and padding output in a unicode-aware way.
The `From` implementation would allow someone to create a `Home` in an
incorrect fashion, for example the path is not canonical.
Exchange `From` for a `TryFrom` implementation.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
This commit allows to checkout a patch created
with `rad patch open` in a new branch
named `patch/{short_patch_id}`.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
This commit includes a simplification in finding the
long patch id in order to perform operations like
`patch show <id>` and `patch checkou <id>`.
Actual output
```
➜ rio git:(main) rad patch list
- YOU PROPOSED -
patch text 8c94760699e R0 f1b2740 (macros/rad_patch) ahead 1, behind 0
└─ * opened by z6MkuvfwAkZ6yD6Z5TT6YXfJjFNPMQz9fPi9BSU7gwhS9s2x (you) 12 minutes ago
└─ * patch id 8c94760699e3e2da64aa9f14f4d2cecfe7b754ad
patch text 78e0fb5ad45 R0 f1b2740 (macros/rad_patch) ahead 1, behind 0
└─ * opened by z6MkuvfwAkZ6yD6Z5TT6YXfJjFNPMQz9fPi9BSU7gwhS9s2x (you) 24 minutes ago
└─ * patch id 78e0fb5ad45481d225a6fb45f51422e468b55c94
- OTHERS PROPOSED -
Nothing to show.
```
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Simplify codebase by splitting patch::create::run() into patch::create::run() and
patch::update::run().
Patch has the subcommands `create` and `update` but both use the same
method to do the heavy lifting. Spitting the code allows us to detangle
the code path making it easier to follow.
Also, reduce cognitive load by minimizing the amount of variables used
and isolating them to utility functions. For instance, `head_branch` can be passed to
these methods instead of `head_oid` and `head_branch`.
Signed-off-by: Slack Coder <slackcoder@server.ky>
Alexis Sellier
xphoniex
Slack Coder
Alexis Sellier
Vincenzo Palazzo
Fintan Halpenny