feat(git): include remote-only branches in getAllBranches

[charlescook-ph]

Summary

• getAllBranches now returns remote-only branches alongside locals (deduplicated by name), so callers that list branches from a freshly-cloned or stale-local checkout see everything that exists on the remote.
• Filters out the remotes/<remote>/HEAD pointer refs that git branch -a emits, so they don't appear in the list as a noisy duplicate of the default branch.

Test plan

• New unit test in packages/git/src/queries.test.ts covers a repo with a local-only branch, a remote-only branch, and verifies HEAD pointer refs are dropped.
• pnpm --filter @posthog/git test passes locally.

---

Created with PostHog Code

[greptile-apps]

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
apps/code/src/renderer/features/work/components/ScheduledTaskEditor.tsx:101-106
The comment here says polling changes "shouldn't clobber user edits," but including `existing` (the full object) in the dependency array defeats that intent. Since `useScheduledTasks` refetches every 30 seconds and returns a new object reference each time, the effect fires on every poll and overwrites whatever the user has typed into the form. Only `existing?.id` needs to be listed so the reset only triggers when the editor is pointed at a different automation.

```suggestion
  // Sync the draft when the editor is pointed at a different existing automation.
  // Only re-run when the id changes — polling produces new object references for
  // the same automation, and we don't want those to overwrite in-progress edits.
  // eslint-disable-next-line react-hooks/exhaustive-deps
  useEffect(() => {
    if (existing) setDraft(toDraft(existing));
  }, [existing?.id]);
```

### Issue 2 of 3
apps/code/src/renderer/api/posthogClient.ts:1073-1085
The `/run/` endpoint is a trigger action that doesn't need a request body. Sending `{} as unknown as Schemas.TaskAutomation` is a double type-cast that silently bypasses TypeScript — if the generated client requires no body for this route the cast can cause a type error elsewhere, and if it's optional the empty object is unnecessary noise. Omitting the `body` property entirely is cleaner and more honest about the API contract.

```suggestion
  async runTaskAutomationNow(
    automationId: string,
  ): Promise<Schemas.TaskAutomation> {
    const teamId = await this.getTeamId();
    const data = await this.api.post(
      `/api/projects/{project_id}/task_automations/{id}/run/`,
      {
        path: { project_id: teamId.toString(), id: automationId },
      },
    );
    return data;
  }
```

### Issue 3 of 3
apps/code/src/renderer/features/work/utils/parseSchedule.test.ts:60-65
**Prefer parameterised tests for tabular assertions**

The team standard is to use parameterised tests rather than multiple bare assertions inside a single `it`. Cases like `parses individual days of the week` (and similar blocks for hourly variants, month variants, etc.) read more clearly and produce better failure output as `it.each` tables. The same pattern applies to the null-return cases, the daily-at-TIME cases, and the Nth-of-month cases throughout this file and `schedulePresets.test.ts`.

_{Reviews (1): Last reviewed commit: "feat(work): scheduled tasks under Work m..." | Re-trigger Greptile}

[greptile-apps]

The comment here says polling changes "shouldn't clobber user edits," but including existing (the full object) in the dependency array defeats that intent. Since useScheduledTasks refetches every 30 seconds and returns a new object reference each time, the effect fires on every poll and overwrites whatever the user has typed into the form. Only existing?.id needs to be listed so the reset only triggers when the editor is pointed at a different automation.

Suggested change

	// Sync the draft when the editor is pointed at a different existing automation.
	useEffect(() => {
	if (existing) setDraft(toDraft(existing));
	// The id is what should trigger a reset — other field changes from polling
	// shouldn't clobber user edits.
	}, [existing?.id, existing]);
	// Sync the draft when the editor is pointed at a different existing automation.
	// Only re-run when the id changes — polling produces new object references for
	// the same automation, and we don't want those to overwrite in-progress edits.
	// eslint-disable-next-line react-hooks/exhaustive-deps
	useEffect(() => {
	if (existing) setDraft(toDraft(existing));
	}, [existing?.id]);

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/features/work/components/ScheduledTaskEditor.tsx
Line: 101-106

Comment:
The comment here says polling changes "shouldn't clobber user edits," but including `existing` (the full object) in the dependency array defeats that intent. Since `useScheduledTasks` refetches every 30 seconds and returns a new object reference each time, the effect fires on every poll and overwrites whatever the user has typed into the form. Only `existing?.id` needs to be listed so the reset only triggers when the editor is pointed at a different automation.

```suggestion
  // Sync the draft when the editor is pointed at a different existing automation.
  // Only re-run when the id changes — polling produces new object references for
  // the same automation, and we don't want those to overwrite in-progress edits.
  // eslint-disable-next-line react-hooks/exhaustive-deps
  useEffect(() => {
    if (existing) setDraft(toDraft(existing));
  }, [existing?.id]);
```

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

The /run/ endpoint is a trigger action that doesn't need a request body. Sending {} as unknown as Schemas.TaskAutomation is a double type-cast that silently bypasses TypeScript — if the generated client requires no body for this route the cast can cause a type error elsewhere, and if it's optional the empty object is unnecessary noise. Omitting the body property entirely is cleaner and more honest about the API contract.

Suggested change

	async runTaskAutomationNow(
	automationId: string,
	): Promise<Schemas.TaskAutomation> {
	const teamId = await this.getTeamId();
	const data = await this.api.post(
	`/api/projects/{project_id}/task_automations/{id}/run/`,
	{
	path: { project_id: teamId.toString(), id: automationId },
	body: {} as unknown as Schemas.TaskAutomation,
	},
	);
	return data;
	}
	async runTaskAutomationNow(
	automationId: string,
	): Promise<Schemas.TaskAutomation> {
	const teamId = await this.getTeamId();
	const data = await this.api.post(
	`/api/projects/{project_id}/task_automations/{id}/run/`,
	{
	path: { project_id: teamId.toString(), id: automationId },
	},
	);
	return data;
	}

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/api/posthogClient.ts
Line: 1073-1085

Comment:
The `/run/` endpoint is a trigger action that doesn't need a request body. Sending `{} as unknown as Schemas.TaskAutomation` is a double type-cast that silently bypasses TypeScript — if the generated client requires no body for this route the cast can cause a type error elsewhere, and if it's optional the empty object is unnecessary noise. Omitting the `body` property entirely is cleaner and more honest about the API contract.

```suggestion
  async runTaskAutomationNow(
    automationId: string,
  ): Promise<Schemas.TaskAutomation> {
    const teamId = await this.getTeamId();
    const data = await this.api.post(
      `/api/projects/{project_id}/task_automations/{id}/run/`,
      {
        path: { project_id: teamId.toString(), id: automationId },
      },
    );
    return data;
  }
```

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Prefer parameterised tests for tabular assertions

The team standard is to use parameterised tests rather than multiple bare assertions inside a single it. Cases like parses individual days of the week (and similar blocks for hourly variants, month variants, etc.) read more clearly and produce better failure output as it.each tables. The same pattern applies to the null-return cases, the daily-at-TIME cases, and the Nth-of-month cases throughout this file and schedulePresets.test.ts.

Context Used: Do not attempt to comment on incorrect alphabetica... (source)

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/features/work/utils/parseSchedule.test.ts
Line: 60-65

Comment:
**Prefer parameterised tests for tabular assertions**

The team standard is to use parameterised tests rather than multiple bare assertions inside a single `it`. Cases like `parses individual days of the week` (and similar blocks for hourly variants, month variants, etc.) read more clearly and produce better failure output as `it.each` tables. The same pattern applies to the null-return cases, the daily-at-TIME cases, and the Nth-of-month cases throughout this file and `schedulePresets.test.ts`.

**Context Used:** Do not attempt to comment on incorrect alphabetica... ([source](https://app.greptile.com/review/custom-context?memory=instruction-0))

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!