@robin I've added implementation notes

I would encourage you to watch the following video on JJ so that the benefits are more apparent

JJ With Git is My New Favorite Workflow

Just to make clear, I'm not actually asking for JJ itself to be implemented in OneDev, but just for the best and most commonly used features to be implemented into the OneDev UI.

Description updated, because unnamed/draft branches may be used as merge targets, but a merge request cannot be opened from a draft source – your work must be finalized (renamed/described) before it lands, even if the receiving branch is still a draft. This is deliberate: the target may be a feature branch that still needs fixing, so the cleanliness requirement applies to what you contribute, not to what receives it.

@robin here is the implementation plan generated by service desk.

Prompt:

Implementation Plan

Design Principles

1. Zero database changes — All state is derived from Git objects themselves (commit messages and ref names). Author identification uses the Git commit author field.
2. Prefix convention — unnamed/ prefix on both commit messages and branch names is the sole detection mechanism. No database table or cache of "namedness."
3. Amend-in-place — Commits are renamed via git commit --amend (new commit object, old one becomes orphaned). This is safe because draft commits are meaningless placeholders; Git GC will clean up orphaned objects naturally.
4. In-place branch rename — Standard git branch -m for renaming branches. The old unnamed/ ref is deleted.
5. Author scoping — UI visibility and rename authority are determined by matching the authenticated user against the Git commit author email of the branch tip commit.
6. Gradual rollout — The feature is opt-in: developers choose "Save as Draft" explicitly. No automatic creation of unnamed branches/commits unless the user intentionally invokes the draft workflow.

Phase 1: Core Detection Utilities (Backend)

Goal: Create a shared utility class that all other phases depend on.

New Java Class: DraftUtil (package: io.onedev.server.git)

public class DraftUtil {
    private static final String UNNAMED_PREFIX = "unnamed/";
    private static final DateTimeFormatter TIMESTAMP_FMT = 
        DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH-mm-ss");

    public static boolean isUnnamedCommit(Commit commit) {
        return commit.getMessage() != null 
            && commit.getMessage().startsWith(UNNAMED_PREFIX);
    }

    public static boolean isUnnamedBranch(String refName) {
        return refName.startsWith("refs/heads/" + UNNAMED_PREFIX);
    }

    public static String generateUnnamedCommitMessage() {
        return UNNAMED_PREFIX + 
            ZonedDateTime.now(ZoneOffset.UTC).format(TIMESTAMP_FMT);
    }

    public static String generateUnnamedBranchName() {
        return UNNAMED_PREFIX + 
            ZonedDateTime.now(ZoneOffset.UTC).format(TIMESTAMP_FMT);
    }

    public static boolean isAuthor(Commit commit, User user) {
        return commit.getAuthor().getEmail().equals(user.getEmail());
    }
}

Note on timestamp format: For commit messages, we can use standard ISO with colons (2024-01-15T14:30:22). For branch names, colons are forbidden in Git refs, so we replace them with hyphens: unnamed/2024-01-15T14-30-22.

Tests

• DraftUtilTest — Unit tests for prefix matching, generation, author detection.

Current State Diagram (Branches Page)

+---------------------------------------------------+
|  Branches Page                                    |
|                                                   |
|  Filter: [Search...]                              |
|                                                   |
|  +----------------------------------------------+ |
|  | Default Branch (main)                        | |
|  |   Last commit: "Add CI pipeline"             | |
|  +----------------------------------------------+ |
|  +----------------------------------------------+ |
|  | feature/user-management                      | |
|  |   Last commit: "Add user roles"              | |
|  +----------------------------------------------+ |
|  +----------------------------------------------+ |
|  | fix/login-bug                                | |
|  |   Last commit: "Fix NPE in login"            | |
|  +----------------------------------------------+ |
|                                                   |
+---------------------------------------------------+

Phase 2: Commit Rename API & UI (Backend + Frontend)

Goal: Allow the author of an unnamed commit to replace the synthetic message with a real one.

2A. REST Endpoint (Backend)

PUT /~api/projects/{projectId}/commits/{commitId}/rename

Request body:

{
  "newMessage": "Fix the widget rendering"
}

Logic:

1. Resolve commitId to a RevCommit.
2. Verify the commit message starts with unnamed/ — if not, return 400.
3. Verify the authenticated user's email matches the commit author's email — if not, return 403.
4. Load the branch(es) that point to this commit (or use branch name from query param).
5. Perform git commit --amend via JGit:
   • Create a new commit with same tree, same parent(s), but new message.
   • Update the branch ref to point to the new commit.
6. Return the new commit SHA and updated branch info.

JGit implementation notes:

try (RevWalk revWalk = new RevWalk(repository)) {
    RevCommit oldCommit = revWalk.parseCommit(ObjectId.fromString(commitId));
    // Create amended commit
    CommitBuilder builder = new CommitBuilder();
    builder.setTreeId(oldCommit.getTree());
    builder.setParentIds(oldCommit.getParents());
    builder.setAuthor(oldCommit.getAuthorIdent());
    builder.setCommitter(new PersonIdent(user.getName(), user.getEmail()));
    builder.setMessage(newMessage);
    ObjectId newCommitId = builder.build(repository);
    // Update ref
    RefUpdate ru = repository.getRefDatabase().getRef(branchName).update();
    ru.setNewObjectId(newCommitId);
    ru.forceUpdate();
}

2B. Frontend Component: CommitTitleEditor.vue

Location: Replaces the read-only commit message display on the commit detail page and in the branch list rows.

Behavior:

• Detects if commit message starts with unnamed/ using the DraftUtil equivalent on the JS side.
• If unnamed: renders the message with faded/dimmed CSS (e.g., opacity: 0.5; color: var(--text-muted); a small (Draft) badge next to it).
• On click: transforms the text into an inline <textarea> pre-filled with any previously typed message (empty by default).
• On blur or Enter: calls PUT /rename endpoint.
• If the rename fails (author mismatch, etc.), shows an inline error and reverts to the original message.
• If the response indicates the old commit became orphaned, a subtle info toast appears: "Draft replaced. Old commit will be cleaned up by Git GC."

State Transitions (Commit Rename)

Current State:
  Branch: unnamed/2024-01-15T14-30-22
  Commit: [abc123] unnamed/2024-01-15T14:30:22
                ↓   (user clicks rename, types "Add user login")
  Branch: unnamed/2024-01-15T14-30-22  (branch unchanged)
  Commit: [def456] Add user login      (new SHA, same tree)
  Orphaned: [abc123]                   (no refs, GC will clean)

Phase 3: Unnamed Branches — UI Visibility & Renaming (Frontend + Backend)

Goal: Display unnamed branches in a separate "Draft Branches" section on the Branches page, and allow inline renaming.

3A. Backend: Branch Filtering Logic

New method in BranchService or GitUtils:

public List<Branch> getUnnamedBranches(Project project, User user) {
    List<Branch> allBranches = getBranches(project);
    return allBranches.stream()
        .filter(b -> DraftUtil.isUnnamedBranch(b.getRefName()))
        .filter(b -> {
            Commit tip = b.getTipCommit();
            return tip != null && DraftUtil.isAuthor(tip, user);
        })
        .collect(Collectors.toList());
}

New REST endpoint or existing branch list enhancement: Modify the existing branches list endpoint to include a draftBranches array alongside namedBranches, or add a query parameter ?type=all|named|draft.

3B. Frontend: BranchesPage.vue Modification

Current layout (simplified):

<div class="branches-page">
  <div class="branch-list">
    <branch-row v-for="branch in branches" :key="branch.name" />
  </div>
</div>

New layout:

<div class="branches-page">
  <div v-if="draftBranches.length > 0" class="draft-branches-section">
    <div class="section-header" 
         :class="{ collapsed: draftBranches.length > 1 }"
         @click="toggleDraftSection">
      <span class="section-title">Draft Branches</span>
      <span v-if="draftBranches.length > 1" class="badge">
        {{ draftBranches.length }} drafts
      </span>
      <span class="collapse-icon">{{ expanded ? '▼' : '▶' }}</span>
    </div>
    <div v-show="expanded || draftBranches.length === 1" 
         class="draft-branch-rows">
      <branch-row v-for="branch in draftBranches" 
                  :key="branch.name" 
                  :branch="branch" 
                  :is-draft="true" />
    </div>
  </div>
  <div class="named-branches-section">
    <div class="section-header">Branches</div>
    <div class="branch-list">
      <branch-row v-for="branch in namedBranches" :key="branch.name" />
    </div>
  </div>
</div>

Collapse logic:

• draftBranches.length === 1 → expanded = true (section open by default)
• draftBranches.length > 1 → expanded = false (section collapsed, badge shown)
• draftBranches.length === 0 → section not rendered at all

3C. Frontend: BranchSelector.vue Modification

For all branch selector dropdowns (branch switcher in header, merge request source/target, compare branches):

<select-option v-for="branch in branches" :key="branch.name"
               :class="{ 'is-draft': branch.isDraft }">
  <span class="branch-name">{{ branch.name }}</span>
  <span v-if="branch.isDraft" class="draft-label">(Draft)</span>
</select-option>

CSS: .is-draft { opacity: 0.6; }

3D. Frontend: Inline Branch Renaming

Add an inline edit feature to the branch row (and the branch detail page header):

• Detection: branch name starts with unnamed/.
• Visual: The name is rendered with faded/dimmed style + (Draft) badge.
• Interaction: Clicking the name switches to an inline <input> field.
• On submit: Call existing branch rename REST API (POST /~api/projects/{projectId}/branches/{oldName}/rename) with the new name.
• Validation: The new name must not start with unnamed/ (no double-draft). If it does, show inline error "Cannot rename to another draft name."

Proposed State Diagram (Branches Page after Phase 3)

+----------------------------------------------------+
|  Branches Page                                     |
|                                                    |
|  +--- Draft Branches (collapsed: 3 drafts) ------+ |
|  | ▶ 3 drafts                                    | |
|  +-----------------------------------------------+ |
|                                                    |
|  +-----------------------------------------------+ |
|  | Default Branch (main)                         | |
|  |   [abc] Add CI pipeline                       | |
|  +-----------------------------------------------+ |
|  +-----------------------------------------------+ |
|  | feature/user-management                       | |
|  |   [def] Add user roles                        | |
|  +-----------------------------------------------+ |
|                                                    |
+----------------------------------------------------+

When expanded:

+---------------------------------------------------+
|  Branches Page                                    |
|                                                   |
|  +--- Draft Branches ---------------------------+ |
|  | ▼ 3 drafts                                   | |
|  | +------------------------------------------+ | |
|  | | unnamed/2024-01-15T14-30-22 (Draft)      | | |
|  | |   [abc123] unnamed/2024-01-15T14:30:22   | | |
|  | +------------------------------------------+ | |
|  | +------------------------------------------+ | |
|  | | unnamed/2024-01-17T09-15-33 (Draft)      | | |
|  | |   [def456] unnamed/2024-01-17T09:15:33   | | |
|  | +------------------------------------------+ | |
|  | +------------------------------------------+ | |
|  | | unnamed/2024-01-18T11-22-44 (Draft)      | | |
|  | |   [ghi789] unnamed/2024-01-18T11:22:44   | | |
|  | +------------------------------------------+ | |
|  +----------------------------------------------+ |
|                                                   |
|  +----------------------------------------------+ |
|  | Default Branch (main)                        | |
|  |   [abc] Add CI pipeline                      | |
|  +----------------------------------------------+ |
|                                                   |
+---------------------------------------------------+

Phase 4: "Save as Draft" in File Editor & Commit Modal (Frontend + Backend)

Goal: Allow users to save in-progress changes as unnamed commits without providing a commit message.

4A. Commit Modal Enhancement

Current behavior: When committing changes via the web UI, there's a modal with a commit message text input and a commit button.

Change: Add a "Save as Draft" checkbox below the commit message input.

Behavior specification (per answer 4):

• The checkbox is labeled "Save as Draft".
• When the checkbox is checked, the commit message text area becomes disabled (read-only). The placeholder text unnamed/2024-01-15T14:30:22 (auto-generated timestamp) is used as the commit message.
• If the user had already typed a message before checking the checkbox, that typed message is stored in a hidden buffer.
• If the user unchecks the checkbox, the text area is re-enabled and the previously typed message is restored from the hidden buffer.
• The commit button text changes to "Commit as Draft" when checkbox is checked.

<div class="commit-modal">
  <textarea v-model="commitMessage" 
            :disabled="isDraft" 
            :placeholder="isDraft ? generatedDraftMsg : 'Describe your changes...'" />
  <label class="draft-checkbox">
    <input type="checkbox" v-model="isDraft" @change="onDraftToggle" />
    Save as Draft
  </label>
  <!-- hidden buffer -->
  <input type="hidden" v-model="savedDraftBuffer" />
  <button @click="submitCommit">
    {{ isDraft ? 'Commit as Draft' : 'Commit' }}
  </button>
</div>

// In the component script
data() {
  return {
    commitMessage: '',
    isDraft: false,
    savedDraftBuffer: '',
    generatedDraftMsg: DraftUtil.generateUnnamedMessage(),
  };
},
methods: {
  onDraftToggle() {
    if (this.isDraft) {
      this.savedDraftBuffer = this.commitMessage;
      this.commitMessage = '';
    } else {
      this.commitMessage = this.savedDraftBuffer;
      this.savedDraftBuffer = '';
    }
  },
  submitCommit() {
    const msg = this.isDraft ? this.generatedDraftMsg : this.commitMessage;
    // call existing commit API with msg
  }
}

4B. File Editor "Save as Draft" Button

Location: The file editor page (FileEditor.vue), typically in the toolbar area.

Current state: A "Commit Changes" button that opens the commit modal.

Change: Add a secondary "Save as Draft" button right next to (or below) "Commit Changes".

Behavior:

• When clicked, immediately creates an unnamed commit from all current uncommitted changes.
• No modal appears — the commit is created instantly.
• The commit message is auto-generated: unnamed/2024-01-15T14:30:22.
• After saving, a success toast appears: "Changes saved as draft."
• The commit appears in the draft branch's history and in the "Draft Branches" section.

Backend endpoint: POST /~api/projects/{projectId}/branches/{branchName}/save-draft

@POST
@Path("/~api/projects/{projectId}/branches/{branchName}/save-draft")
public BranchData saveDraft(
    @PathParam("projectId") Long projectId,
    @PathParam("branchName") String branchName,
    @Auth User user) {
    // 1. Verify the branch is unnamed (or create if it doesn't exist)
    // 2. Stage all uncommitted changes from the editor's working tree
    // 3. Create a commit with auto-generated message
    // 4. Push the commit to the branch
    // 5. Return updated branch info
}

4C. "You have uncommitted changes" Indicator

Location: File editor page, persistent banner or snackbar.

<div v-if="hasUncommittedChanges" class="unsaved-indicator">
  <span>⚠ You have uncommitted changes</span>
  <button @click="saveAsDraft">Save as Draft</button>
  <button @click="openCommitModal">Commit Changes</button>
</div>

Phase 5: Commit Splitting — Staging Hunks/Files (Backend + Frontend)

Goal: Allow users to split an unnamed commit by moving selected hunks (or entire files) into a new preceding commit that must be named.

Constraint: This feature is only available for unnamed commits on the current branch's tip (the latest unnamed commit in the draft workflow).

5A. Backend: Split Commit Endpoint

POST /~api/projects/{projectId}/branches/{branchName}/split-commit

Request body:

{
  "selectedHunks": [
    {"file": "src/main/java/App.java", "hunkIndex": 0},
    {"file": "src/main/java/App.java", "hunkIndex": 2}
  ],
  "selectedFiles": [
    "src/main/java/Utils.java"
  ],
  "newCommitMessage": "Refactor user authentication logic"
}

Logic:

1. Parse the current unnamed tip commit.
2. Get its diff against its parent.
3. From the selected hunks/files, reconstruct two diffs:
   • Selected diff: contains only the selected hunks + entire selected files.
   • Remainder diff: contains everything else.
4. Create a new named commit (using newCommitMessage) by applying the selected diff to the parent tree.
   • This commit becomes the preceding commit.
5. Create a new unnamed commit by applying the remainder diff on top of the preceding commit.
   • This becomes the new tip.
6. Update the branch ref to point to the new unnamed tip.
7. Return the two new commit SHAs.

Current State Diagram (Before Split)

  Parent (named commit)
      |
  Current unnamed commit (tip)
  [abc123] unnamed/2024-01-15T14:30:22
      |
  Diff includes:
    - App.java hunk 0: change login logic
    - App.java hunk 1: change validation  
    - App.java hunk 2: add logging
    - Utils.java: entire file (new helper)

Proposed State Diagram (After Split)

  Parent (named commit)
      |
  New preceding commit (named - forced)
  [def456] Refactor user authentication logic
      |
  Contains: App.java hunk 0 + Utils.java
      |
  New unnamed commit (remainder)
  [ghi789] unnamed/2024-01-15T14:30:22
      |
  Contains: App.java hunk 1 + App.java hunk 2

5B. Frontend: CommitDiffView.vue Modification

Current state: Displays a unified or split diff of the commit, with hunks shown in expandable regions.

Change: When viewing the diff of the current unnamed tip commit, each hunk gains a "+" icon (or a staging checkbox) at the top-left corner. Each file header gains an entire-file checkbox.

<template>
  <div class="commit-diff">
    <file-diff v-for="file in files" :key="file.path">
      <template #file-header>
        <input type="checkbox" v-model="file.selected" 
               @change="onFileSelect(file)" />
        <span class="file-path">{{ file.path }}</span>
      </template>
      <hunk v-for="(hunk, idx) in file.hunks" :key="idx">
        <template #hunk-header>
          <button v-if="isDraftCommit" 
                  class="stage-hunk-btn" 
                  @click="stageHunk(file, idx)"
                  title="Stage this hunk into preceding commit">
            +
          </button>
          <span class="hunk-info">{{ hunk.header }}</span>
        </template>
        <diff-line v-for="line in hunk.lines" :key="line.num" />
      </hunk>
    </file-diff>
    <button v-if="hasSelectedHunks" 
            class="split-commit-btn"
            @click="openSplitModal">
      Split Selected into New Commit
    </button>
  </div>
</template>

5C. New Component: CommitSplitModal.vue

Behavior:

• Activated when user clicks "Split Selected into New Commit".
• Shows a modal with:
  • Summary of what's being split (e.g., "3 hunks from 2 files").
  • A multiline text input for the new commit message (required, non-empty).
  • "Split" button (disabled until a message is entered).
  • "Cancel" button.
• On submit, calls POST /split-commit endpoint.
• On success, refreshes the diff view to show the new state.
• On error, shows error message in modal.

<modal :open="show" @close="cancel">
  <h3>Split Commit</h3>
  <p>Extracting {{ selectedHunkCount }} hunks into a new preceding commit.</p>
  <label>Commit message for the new preceding commit:</label>
  <textarea v-model="newMessage" rows="4" 
            placeholder="Describe what this commit does..." />
  <div class="actions">
    <button :disabled="!newMessage.trim()" @click="split">Split</button>
    <button @click="cancel">Cancel</button>
  </div>
</modal>

Phase 6: Merge Request Restrictions (Backend + Frontend)

Goal: Prevent premature merging of draft work.

6A. Backend Checks

In PullRequestService (or merge request creation logic):

public void checkCanCreatePullRequest(Project project, Branch sourceBranch, User user) {
    if (DraftUtil.isUnnamedBranch(sourceBranch.getRefName())) {
        throw new UnnamedBranchException(
            "Cannot create merge request from an unnamed branch. " +
            "Please rename the branch first.");
    }
    // Additionally check commits
    for (Commit commit : getCommits(sourceBranch)) {
        if (DraftUtil.isUnnamedCommit(commit) 
            && DraftUtil.isAuthor(commit, user)) {
            throw new UnnamedCommitException(
                "Cannot merge while unnamed commits exist. " +
                "Please describe all draft commits first.");
        }
    }
}

In merge endpoint (actual merge execution):

Same check to prevent programmatic merges as well.

6B. Frontend: Disable "Create Merge Request" Button

In the branch detail page and the branches list:

<button :disabled="branch.isUnnamed" 
        :title="branch.isUnnamed ? 'Cannot create merge request from a draft branch' : ''"
        @click="createMergeRequest">
  Create Merge Request
</button>

Add a tooltip explaining why it's disabled and how to fix it ("Rename the branch and describe all commits first").

6C. Merge Check UI Indicator

On the merge request page itself, if the source branch still has unnamed commits:

<div class="merge-blocked-banner">
  <span class="icon">🚫</span>
  <span>Merge blocked: {{ unnamedCommitCount }} unnamed commit(s) remain. 
         Please rename or describe them before merging.</span>
  <button v-if="canFix" @click="goToBranch(branch.name)">
    Review Draft Commits
  </button>
</div>

Phase 7: Integration & Edge Cases (All Layers)

7A. Unnamed Branch with No Commits (Orphan Branch)

If a branch is created with unnamed/ prefix but has no commits yet (empty branch), the author cannot be determined from a tip commit. In this case:

• Show the branch in "Draft Branches" only to the user who created it (using the OneDev branch creator metadata if available), or
• Show it to all users but with an "unknown author" indicator.
• Decision per answer 4: Author is determined by the branch creator metadata (OneDev tracks who created each branch internally).

7B. Mixed State Support

The system must handle all four states from the issue:

7C. Orphaned Commit Cleanup

As agreed in answer 2b, old commits become orphaned after rename. No explicit cleanup is needed — Git GC handles this. However, for the user experience, add an informational toast after rename: "Draft replaced. Previous draft will be cleaned up automatically."

7D. Author Scoping Edge Cases

• Commits with multiple authors: Use the committer field (the person who committed) as the "author" for UI visibility, as this is the authenticated user who performed the draft action.
• Rebased branches: If a branch is force-pushed from CLI with unnamed commits, the author field still determines visibility. If a non-author force-pushes an unnamed commit authored by someone else, the commit will be invisible to everyone in the UI (since its author matches neither the pusher nor the current viewer). This is acceptable per the issue's rationale.

Summary: Files to Create / Modify

New Files

Modified Files

Testing Plan

Unit Tests (all phases)

• DraftUtilTest: prefix matching, timestamp generation, author matching
• DraftResourceTest: rename endpoint (success, 400, 403), save-draft endpoint, split-commit endpoint
• PullRequestServiceTest: merge request creation blocked for unnamed branches/commits

Integration Tests (all phases)

• E2E: Create unnamed branch via web UI → verify it appears in "Draft Branches"
• E2E: Edit files, "Save as Draft" → verify unnamed commit created
• E2E: Rename unnamed commit → verify new message appears, old commit gone
• E2E: Split commit → verify two commits (named preceding + unnamed tip)
• E2E: Verify "Create Merge Request" button disabled for unnamed source branch
• E2E: Attempt merge with unnamed commits → verify blocked

Visual Regression Tests (frontend)

• Draft Branches section: single draft (expanded), multiple drafts (collapsed), zero drafts (hidden)
• Branch selector dropdowns: unnamed branch shown with dimmed styling
• Commit diff view: + icon appears only for unnamed tip commit

Risk & Mitigation Table

This plan covers all five features described in issue #3103 without scope creep, using the agreed design decisions (prefix convention, amend-in-place, inline renaming, draft checkbox in commit modal, no pre-existing UI for drafts). All phases can be implemented in the order shown, with each phase building on the previous one's APIs and utilities.