Focus a repository and configure Git tools

Large repositories, large assets and different signing identities need different controls. Open the relevant action for the active repository, inspect the preview and apply only the change needed for your task.

Focus a monorepo with sparse checkout

1. Open sparse checkout and select the directories you need. Filtering the list preserves your selections; selecting a parent makes its child selections redundant.
2. Review the visible-file count. Cone mode keeps the selected directories, files at the root and files directly inside ancestor directories.
3. Choose sparse index only if your other Git tools support it. It can reduce the index size; it does not guarantee faster builds or install project dependencies.
4. Apply the reviewed selection. Pending edits, ignored files or another Git operation can block the change. Resolve the reported state and generate a fresh preview if the repository changed.
5. Use the restore-full-tree action when you need all tracked files again.

This changes which tracked files are present in the working tree, not the repository's complete history. It does not perform a partial clone. Existing non-cone configurations can be disabled but are not edited by the selector. Current limits are 250,000 files, 20,000 directories and 1,000 selected directories; an exceeded limit is reported rather than silently truncating the selection.

Manage large files with Git LFS

Open the repository extensions panel to inspect Git LFS, its files, object availability and rules in the root .gitattributes. Actions require Git LFS 3.8.1 or later installed on your computer.

1. Install the LFS configuration for this repository if needed. This configures the repository; it does not install the Git LFS executable. Shared or unsafe hook paths can prevent the action, and existing hooks are not forcibly replaced.
2. Add or remove a tracking pattern and confirm it. Review the resulting .gitattributes change and commit it when appropriate.
3. Select a remote to fetch LFS objects for HEAD. Then materialize available objects in the working files when needed.

The panel displays up to 2,000 files and reports partial coverage. It does not edit every nested attributes file, migrate existing history into LFS, prune objects or automatically upload them. Tracking a pattern alone does not convert past commits.

Update a submodule deliberately

In the same panel, select a submodule and compare its current commit with the commit recorded in the parent repository's index. Inspect initialization and pending changes before updating.

The update initializes when necessary, fetches and checks out the recorded commit in detached HEAD. It does not advance to the latest remote branch, change the parent's recorded commit or recursively update nested submodules. Dirty or unsafe paths and ongoing operations are refused. Open the submodule as its own Riff context to work on it.

A canceled fetch can leave downloaded objects or a partially initialized submodule. Read the refreshed state before retrying; cancellation does not imply that every earlier step was undone.

Apply an identity or signing profile

1. Open repository identity and inspect the effective author, configuration source and organization policy. Choose the Git identity, the Gapfy account where available, or the default behavior allowed by that policy.
2. Save a named profile for reuse. Saving or loading it does not change the repository; review and confirm Apply separately.
3. Choose inherited signing, OpenPGP or SSH as needed. Supply a key identifier or public SSH key reference. Riff does not import or store private signing keys. Disabling signing requires an explicit choice.
4. Check the target scope. With worktree-specific configuration enabled, Apply changes that worktree; otherwise it changes the repository's shared configuration. It does not rewrite global configuration or included files.
5. Inspect the signature of HEAD. The result distinguishes no commit, unsigned, valid and unverified signatures without creating a test commit.

Organization identity policy takes precedence over a profile. Local verification does not prove that the next commit can be signed or that a remote host trusts the signature. Configure the signing tool, agent and trust separately as required by your organization.

For dependent branches, use stacks and coordinated publication. For independent tasks, use work contexts and worktrees.