Files
Chandler Carruth 681b3b10c4 Add a jj push wrapper that runs prek before pushing. (#7805)
`scripts/jj_push.sh` takes the same arguments as `jj git push`, runs
prek over the commits that push would send, and pushes only if they
pass. It learns what is being sent by running `jj git push --dry-run`
and reading back the plan, so `--bookmark`, `--change`, `--all` and the
rest work without reimplementing how they select commits.

Hooks that rewrite files need a commit to write into, so the checks run
with the working copy on top of the commit being pushed. When the
working copy is already an empty commit there, which is the common case,
it is used directly; otherwise one is created, and named in the error so
the fixes can be squashed.

`scripts/jj_prek.sh` gets two changes. It forwards its arguments to
`prek run`, so `jj_push.sh` can ask for a specific range, and it now
changes to the workspace root before running. It exports `GIT_DIR`,
which makes git treat the current directory as the work tree, so prek
could not find its configuration from a subdirectory.

`jj` does not expand aliases when completing arguments, so `jj push`
completed file names. `scripts/completions` has Bash, Zsh, and Fish
completions that give it the same completions as `jj git push`.

`docs/project/contribution_tools.md` documents the `push` alias, and a
`prek` alias for `jj_prek.sh`, with the other per-repository `jj`
configuration. Both are opt-in.

Assisted-by: Claude Code
2026-09-18 19:40:25 +00:00
..
2026-09-15 00:03:41 +00:00

Docs

This directory contains current, accepted documentation underpinning Carbon. These documents cover all aspects of Carbon ranging from the project down to detailed designs for specific language features.

If you're trying to learn more about Carbon, we recommend starting at /README.md.

Design

Carbon language's design and rationale are documented in the design/ directory. This documentation is intended to support the following audiences:

  • People who wish to determine whether Carbon would be the right choice for a project compared to other existing languages.
  • People working on the evolution of the Carbon language who wish to understand the rationale and motivation for existing design decisions.
  • People working on a specification or implementation of the Carbon language who need a detailed understanding of the intended design.
  • People writing Carbon code who wish to understand why the language rules are the way they are.

This is in contrast to proposals, which document the individual decisions that led to this design (along with other changes to the Carbon project), including the rationale and alternatives considered.

Project

The project/ directory contains project-related documentation for Carbon, including:

  • goals, and the principles and roadmap derived from those goals,
  • how the project works, and
  • how to contribute.

Guides

The guides/ directory contains to-be-written end-user documentation for developers writing programs in Carbon.

Spec

The spec/ directory contains the to-be-written formal specification of the Carbon language. This is for implementers of compilers or other tooling. This is intended to complement the toolchain.