feat(cli): Add --include-logs option for git commit history#793
feat(cli): Add --include-logs option for git commit history#793
Conversation
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughAdds optional Git log collection and inclusion across the toolchain: CLI flags/config, git log command/handler, security-check tasks, token-count metrics (worker), output generation/templates/types, reporting, packager wiring, and tests. Public signatures and types expanded to thread Git log data. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor User
participant CLI as CLI
participant Pack as Packager
participant GitH as Git Log Handle
participant Sec as Security Check
participant Met as Metrics
participant Out as Output Gen
participant Rep as Reporter
User->>CLI: run (--include-logs [--include-logs-count])
CLI->>Pack: pack(config with git.includeLogs/count)
Pack->>GitH: getGitLogs(rootDirs[0], count)
alt logs disabled or not a repo
GitH-->>Pack: undefined
else
GitH-->>Pack: { logContent, commits }
end
par metrics and security
Pack->>Met: calculateGitLogMetrics(config, gitLogResult)
Pack->>Sec: runSecurityCheck(files, gitDiffResult, gitLogResult)
and
Met-->>Pack: gitLogTokenCount
Sec-->>Pack: suspiciousGitLogResults
end
Pack->>Out: generateOutput(..., gitDiffResult, gitLogResult)
Out-->>Pack: rendered output
Pack->>Rep: report(summary, suspiciousFiles, suspiciousGitDiffs, suspiciousGitLogs)
Rep-->>User: display report
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related issues
Possibly related PRs
Suggested labels
✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
Deploying repomix with
|
| Latest commit: |
1175bfb
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://cdc9c630.repomix.pages.dev |
| Branch Preview URL: | https://feat-include-logs.repomix.pages.dev |
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
There was a problem hiding this comment.
Summary of Changes
Hello @yamadashy, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request introduces a new --include-logs option to the CLI, allowing users to incorporate Git commit history into the output. This feature is designed to provide AI systems with richer context, enabling them to better understand development patterns, file change relationships, and the evolution of the codebase.
Highlights
- CLI Options: Added --include-logs flag to enable Git log inclusion and --include-logs-count to specify the number of commits. Help documentation and README have been updated accordingly.
- Configuration Support: New includeLogs and includeLogsCount options have been added to the configuration schema, supporting both CLI flags and configuration file settings.
- Core Implementation: A new module src/core/git/gitLogHandle.ts was created for Git log processing, and src/core/git/gitCommand.ts was extended with an execGitLog function. Git logs are now integrated into the packager workflow, including security checks, token counting, and metrics.
- Output Templates: All output styles (XML, Markdown, Plain) have been updated to include a dedicated Git logs section with proper formatting and styling. Summary notes also mention Git logs inclusion.
- Testing & Quality: Comprehensive test coverage has been added for all new functionality. Existing tests were updated to handle new function signatures, and all 721 tests are passing. TypeScript compilation errors were also fixed.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request introduces a valuable feature to include git commit history in the output, which will certainly enhance the context provided to AI models. The implementation is comprehensive, touching on configuration, core logic, security, metrics, and output formats. I've identified a couple of high-severity issues, including a bug in the plain text output template and a potential for swallowed errors in the new git log handler. I've also noted some areas with code duplication that could be refactored for better maintainability. A key concern is the lack of new unit tests for the newly created modules. While existing tests were updated, adding dedicated tests for the new functionality is crucial for ensuring long-term quality and stability. Please see my detailed comments for suggestions.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #793 +/- ##
==========================================
- Coverage 88.59% 87.49% -1.11%
==========================================
Files 110 113 +3
Lines 6192 6437 +245
Branches 1282 1316 +34
==========================================
+ Hits 5486 5632 +146
- Misses 706 805 +99 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (38)
src/core/git/gitCommand.ts (1)
153-177: Harden git log output: disable ANSI color and use strict ISO dates
- Add --no-color to avoid user config leaking ANSI sequences into logs.
- Prefer --date=iso-strict for unambiguous ISO 8601 formatting.
- Optional: use a tab delimiter between date/subject to minimize collisions with commit subjects using '|' (not strictly required since you’re not parsing this).
Apply this diff:
export const execGitLog = async ( directory: string, maxCommits = 50, deps = { execFileAsync, }, ): Promise<string> => { try { const result = await deps.execFileAsync('git', [ '-C', directory, 'log', - '--pretty=format:%ad|%s', - '--date=iso', + '--no-color', + '--pretty=format:%ad\t%s', + '--date=iso-strict', '--name-only', '-n', maxCommits.toString(), ]); return result.stdout || ''; } catch (error) { logger.trace('Failed to execute git log:', (error as Error).message); throw error; } };README.md (3)
263-277: Clarify behavior, defaults, and scope for git logs (add explicit notes)
- Explicitly mention commit hashes are excluded (as designed).
- Warn about increased token usage when logs are enabled.
- Note that logs require a local Git work tree; remote processing may not include logs if .git metadata isn’t available (current clone flow removes .git).
Apply this diff:
To include git logs in the output: ```bash # Include git logs with default count (50 commits) repomix --include-logs # Include git logs with specific commit count repomix --include-logs --include-logs-count 10 # Combine with diffs for comprehensive git context repomix --include-logs --include-diffs-The git logs include commit dates, messages, and file paths for each commit, providing valuable context for AI analysis of code evolution and development patterns.
+The git logs include commit dates, messages, and file paths for each commit, providing valuable context for AI analysis of code evolution and development patterns.
+
+> [!NOTE]
+> - Commit hashes are intentionally excluded from the output.
+> - Enabling logs will increase token usage (reported as gitLogTokenCount in metrics).
+> - Git logs are available only when Repomix runs inside a Git repository (i.e., a directory with a .git work tree). When processing remote repositories, logs may be unavailable if repository metadata is not present.Would you like the docs to also show a brief example snippet of the Git Logs section in each output style (XML/Markdown/Plain) for completeness? --- `551-553`: **Document minimum constraints for include-logs-count** The schema enforces an integer with min 1. Reflect this here to reduce ambiguity. ```diff - `--include-logs`: Include git logs in the output (includes commit history with dates, messages, and file paths) -- `--include-logs-count <count>`: Number of git log commits to include (default: 50) +- `--include-logs-count <count>`: Number of git log commits to include (default: 50, min: 1)
948-950: Make config constraints explicitSurface the min 1 constraint for includeLogsCount in the table, matching the schema.
-| `output.git.includeLogs` | Whether to include git logs in the output (includes commit history with dates, messages, and file paths) | `false` | -| `output.git.includeLogsCount` | Number of git log commits to include | `50` | +| `output.git.includeLogs` | Whether to include git logs in the output (includes commit history with dates, messages, and file paths) | `false` | +| `output.git.includeLogsCount` | Number of git log commits to include (min 1) | `50` |src/core/output/outputStyleDecorate.ts (1)
189-190: Prefer nullish coalescing to preserve explicit zero valuesUsing
||will treat0as falsy and fallback to50. If0is ever a valid explicit choice (or to follow type-default semantics more precisely), switch to??.- const logCount = config.output.git?.includeLogsCount || 50; + const logCount = config.output.git?.includeLogsCount ?? 50;Optional: If
0should be clamped, considerMath.max(1, includeLogsCount ?? 50).tests/cli/actions/remoteAction.test.ts (1)
39-53: Reduce duplication of PackResult stubs across testsThe inline
packResultshape is repeated in multiple tests. Consider extracting a small factory/helper to keep test fixtures DRY and easier to evolve when fields are added in the future.Example:
function createPackResult(overrides: Partial<typeof base> = {}) { const base = { totalFiles: 1, totalCharacters: 1, totalTokens: 1, fileCharCounts: {}, fileTokenCounts: {}, suspiciousFilesResults: [], suspiciousGitDiffResults: [], suspiciousGitLogResults: [], processedFiles: [], safeFilePaths: [], gitDiffTokenCount: 0, gitLogTokenCount: 0, }; return { ...base, ...overrides }; }Then use
packResult: createPackResult()in each test to avoid repetition.src/core/output/outputStyles/xmlStyle.ts (1)
67-74: Ensure XML-safe rendering for Git log contentUsing triple mustaches (
{{{gitLogContent}}}) disables escaping. IfgitLogContentis not already XML-escaped or CDATA-wrapped upstream, commit messages containing<,>, or&will break well-formedness. Please confirm the upstream handling matches that used for file contents and diffs.Two safe options:
- Escape here by switching to double mustaches:
-{{{gitLogContent}}} +{{gitLogContent}}
- Or wrap in CDATA (ensure
]]>is handled/split upstream):<git_log_content><![CDATA[ {{{gitLogContent}}} ]]></git_log_content>Pick one consistent with how
gitDiff*and file contents are sanitized in the XML pipeline.src/core/output/outputStyles/markdownStyle.ts (1)
64-71: Use a language hint and consider fence robustness for commit messagesMinor UX improvement: specify a language for the logs code block to prevent odd highlighting and improve readability. Also, commit messages can occasionally contain triple backticks; while rare, consider switching to tildes (~~~) or a longer fence if you observe breakage.
-# Git Logs -``` -{{{gitLogContent}}} -``` +# Git Logs +```text +{{{gitLogContent}}} +```If you’d like, I can follow up with a small helper to auto-pick a safe fence if content contains ``` or ~~~.
src/cli/actions/defaultAction.ts (1)
292-310: CLI flags merged correctly; consider explicit disable semanticsMerging includeLogs/includeLogsCount into output.git is correct. One consideration: currently there’s no way via CLI to explicitly disable logs if the config enables them (no --no-include-logs handling). If that’s intentional per the CLI design, ignore this. If you intend to support disabling via CLI, add an explicit false branch similar to gitSortByChanges.
if (options.includeLogs) { cliConfig.output = { ...cliConfig.output, git: { ...cliConfig.output?.git, includeLogs: true, }, }; } +// If a --no-include-logs flag is ever introduced, honor it here: +if (options.includeLogs === false) { + cliConfig.output = { + ...cliConfig.output, + git: { + ...cliConfig.output?.git, + includeLogs: false, + }, + }; +}tests/cli/cliRun.test.ts (1)
97-100: PackResult fixture extended with gitLog fields: looks good; add a passthrough test for new CLI flags.*Adding gitLogTokenCount and suspiciousGitLogResults keeps tests aligned with the new PackResult shape. To prevent regressions, add a test ensuring runCli forwards --include-logs and --include-logs-count to defaultAction.
Proposed test to add in this file:
describe('git logs flags', () => { test('should pass --include-logs and --include-logs-count to default action', async () => { await runCli(['.'], process.cwd(), { includeLogs: true, includeLogsCount: 10 }); expect(defaultAction.runDefaultAction).toHaveBeenCalledWith( ['.'], process.cwd(), expect.objectContaining({ includeLogs: true, includeLogsCount: 10, }), ); }); });Also applies to: 152-155
tests/cli/actions/defaultAction.test.ts (1)
105-110: LGTM on new git log fields in PackResult mocks; cover CLI→config merge for logs.The added suspiciousGitLogResults and gitLogTokenCount fields keep mocks current. Consider adding a focused test to verify buildCliConfig merges includeLogs/includeLogsCount into the config.git section passed to mergeConfigs.
Add something like:
it('should handle --include-logs and --include-logs-count flags', async () => { const options: CliOptions = { includeLogs: true, includeLogsCount: 12, }; await runDefaultAction(['.'], process.cwd(), options); expect(configLoader.mergeConfigs).toHaveBeenCalledWith( process.cwd(), expect.anything(), expect.objectContaining({ output: expect.objectContaining({ git: expect.objectContaining({ includeLogs: true, includeLogsCount: 12, }), }), }), ); });Also applies to: 659-665, 790-791, 795-796, 859-865
src/cli/cliRun.ts (1)
99-104: Validate --include-logs-count to avoid NaN/negative/huge values.Currently parsed with Number.parseInt without range checks. Add a parser that enforces a sane positive range and throws a RepomixError on invalid input.
Apply this diff:
.option( '--include-logs', 'include git logs in the output (includes commit history with dates, messages, and file paths)', ) - .option('--include-logs-count <count>', 'number of git log commits to include (default: 50)', Number.parseInt) + .option( + '--include-logs-count <count>', + 'number of git log commits to include (1-1000, default: 50)', + (value: string) => { + const n = Number.parseInt(value, 10); + if (!Number.isFinite(n) || n <= 0 || n > 1000) { + throw new RepomixError("Invalid value for --include-logs-count. Must be an integer between 1 and 1000."); + } + return n; + }, + )Optional: extend the semanticSuggestionMap with entries like history, changelog → --include-logs to improve UX when users try related terms.
tests/core/metrics/diffTokenCount.test.ts (1)
103-109: Signature adaptation LGTM; also assert gitLogTokenCount stays 0 when logs are unused.You’ve added the new git-log argument and mocked calculateGitLogMetrics. To harden expectations, assert that result.gitLogTokenCount is present and zero in these cases.
Add assertions after the calculateMetrics invocation in each test:
expect(result).toHaveProperty('gitLogTokenCount'); expect(result.gitLogTokenCount).toBe(0);Also applies to: 178-184, 251-257
tests/core/output/diffsInOutput.test.ts (2)
126-131: Nit: Align mocked context shape with new APIThis test’s mocked
buildOutputGeneratorContextearlier returnsgitDiffs: sampleDiff(Line 107), while the rest of the suite moved togitDiffResult. Consider returning{ gitDiffResult: { workTreeDiffContent: sampleDiff, stagedDiffContent: '' } }for consistency and future-proofing.
126-131: Nit: Test name suggests XML path, but code executes Handlebars pathSince
mockConfig.output.parsableStyleis falsy, the XML generator won’t be invoked here. If you want to assert the XML path (and exercisemockGenerateParsableXmlOutput’srenderContextchecks), setparsableStyle: truefor this test.tests/core/security/validateFileSafety.test.ts (1)
28-31: Optional: Add a case that includes Git log security resultsTo harden coverage for the new path, add a test where
runSecurityCheckreturns an item withtype: 'gitLog'and assert it appears undersuspiciousGitLogResults.tests/core/output/outputGenerate.test.ts (1)
43-51: Optional: Add a dedicated test covering gitLog integrationGiven
generateOutputnow threadsgitLogResultthroughbuildOutputGeneratorContextand intocreateRenderContext, consider a test that setsgitLogResultwith content and asserts it’s present in the render context and final output (for both parsable XML and non-parsable styles).tests/core/security/securityCheck.test.ts (1)
161-163: Optional: Add coverage for Git log tasksNow that
runSecurityCheckacceptsgitLogResult, it’s worth adding a test to ensure:
- A
gitLogResultwithlogContentcreates agitLogtask- The progress callback includes “Git log history”
- Results aggregate any issues under
type: 'gitLog'Example snippet to add at the end of this suite:
it('should process Git log content when gitLogResult is provided', async () => { const gitLogResult = { logContent: '2025-08-18T12:34:56Z chore: bump deps\nM package.json' }; const progressCallback = vi.fn(); const result = await runSecurityCheck(mockFiles, progressCallback, undefined, gitLogResult, { initTaskRunner: mockInitTaskRunner, }); // 2 file tasks + 1 git log task expect(progressCallback).toHaveBeenCalledTimes(3); expect(progressCallback).toHaveBeenCalledWith(expect.stringContaining('Git log history')); // Depending on worker logic, may or may not flag issues in the log; assert type presence if any if (result.some((r) => r.type === 'gitLog')) { expect(result.find((r) => r.type === 'gitLog')?.filePath).toBe('Git log history'); } });tests/core/metrics/calculateMetrics.test.ts (1)
58-63: Nit: Assert calculateGitLogMetrics invocationFor completeness, assert the new metrics function is called with
(config, gitLogResult):const calculateGitLogMetrics = vi.fn().mockResolvedValue({ gitLogTokenCount: 0 }); const result = await calculateMetrics( processedFiles, output, progressCallback, config, gitDiffResult, undefined, { calculateSelectiveFileMetrics, calculateOutputMetrics: () => Promise.resolve(30), calculateGitDiffMetrics: () => Promise.resolve(0), calculateGitLogMetrics, // spy }, ); expect(calculateGitLogMetrics).toHaveBeenCalledWith(config, undefined);src/core/security/securityCheck.ts (2)
10-14: Avoid duplicating SuspiciousFileResult type; re-export instead.This interface appears to duplicate the one in workers/securityCheckWorker.ts. Duplications are brittle and can drift.
Apply this diff to re-use the worker’s type:
-import type { SecurityCheckTask, SecurityCheckType } from './workers/securityCheckWorker.js'; +import type { SecurityCheckTask, SecurityCheckType } from './workers/securityCheckWorker.js'; +export type { SuspiciousFileResult } from './workers/securityCheckWorker.js'; - -export interface SuspiciousFileResult { - filePath: string; - messages: string[]; - type: SecurityCheckType; -}
58-61: Avoid spinning up a worker pool when there’s nothing to do.Minor optimization: if there are zero tasks (no files, no diffs, no logs), return early and skip initTaskRunner.
- const taskRunner = deps.initTaskRunner<SecurityCheckTask, SuspiciousFileResult | null>( - rawFiles.length + gitDiffTasks.length + gitLogTasks.length, - new URL('./workers/securityCheckWorker.js', import.meta.url).href, - ); + const totalPlannedTasks = rawFiles.length + gitDiffTasks.length + gitLogTasks.length; + if (totalPlannedTasks === 0) { + logger.trace('No items to security-check; skipping.'); + return []; + } + const taskRunner = deps.initTaskRunner<SecurityCheckTask, SuspiciousFileResult | null>( + totalPlannedTasks, + new URL('./workers/securityCheckWorker.js', import.meta.url).href, + );tests/cli/cliReport.test.ts (2)
36-49: PackResult fixture updated with git logs fields — add an assertion?The wiring looks correct (suspiciousGitLogResults, gitLogTokenCount). Consider adding a summary assertion when logs are present in PackResult, to exercise that path.
Example extension:
+ const packResultWithLogIssues: PackResult = { + ...packResult, + suspiciousGitLogResults: [{ filePath: 'Git log history', messages: ['token found'], type: 'gitLog' }], + }; + reportSummary(packResultWithLogIssues, config); + expect(logger.log).toHaveBeenCalledWith(expect.stringContaining('Git logs'));
97-102: LGTM: callsite updated; consider adding a test for git-log issues reporting.You already cover files and diffs; one focused test verifying the git logs section would improve coverage.
Add:
+ test('should print details of suspicious git logs when found', () => { + const config = createMockConfig({ security: { enableSecurityCheck: true } }); + reportSecurityCheck('/root', [], [], [{ filePath: 'Git log history', messages: ['Contains token'], type: 'gitLog' }], config); + expect(logger.log).toHaveBeenCalledWith('YELLOW:1 security issue(s) found in Git logs:'); + expect(logger.log).toHaveBeenCalledWith('WHITE:1. WHITE:Git log history'); + expect(logger.log).toHaveBeenCalledWith('DIM: - 1 security issue detected'); + });src/core/metrics/calculateMetrics.ts (1)
52-62: Rename destructured value to avoid shadowing and improve clarity.
gitLogTokenCountvariable holds an object with a homonymous field; reads oddly. Rename togitLogMetricsor destructure.Apply one of:
- const [selectiveFileMetrics, totalTokens, gitDiffTokenCount, gitLogTokenCount] = await Promise.all([ + const [selectiveFileMetrics, totalTokens, gitDiffTokenCount, gitLogMetrics] = await Promise.all([ @@ - deps.calculateGitLogMetrics(config, gitLogResult), + deps.calculateGitLogMetrics(config, gitLogResult), ]);and later:
- gitLogTokenCount: gitLogTokenCount.gitLogTokenCount, + gitLogTokenCount: gitLogMetrics.gitLogTokenCount,Or destructure:
- const [selectiveFileMetrics, totalTokens, gitDiffTokenCount, gitLogTokenCount] = await Promise.all([...]); + const [selectiveFileMetrics, totalTokens, gitDiffTokenCount, { gitLogTokenCount }] = await Promise.all([...]);tests/integration-tests/packager.test.ts (1)
134-158: Stubbed calculateMetrics updated; trim excess properties to match the contract.The return object includes fields (suspiciousFilesResults, suspiciousGitDiffResults) that aren’t part of CalculateMetricsResult and may trigger excess property checks under stricter TS flags.
Apply this diff to keep the stub tightly typed:
- calculateMetrics: async (processedFiles, output, progressCallback, config, gitDiffResult, gitLogResult) => { - return { + calculateMetrics: async (processedFiles, output, progressCallback, config, gitDiffResult, gitLogResult) => { + return { totalFiles: processedFiles.length, totalCharacters: processedFiles.reduce((acc, file) => acc + file.content.length, 0), totalTokens: processedFiles.reduce((acc, file) => acc + file.content.split(/\s+/).length, 0), gitDiffTokenCount: 0, gitLogTokenCount: 0, fileCharCounts: processedFiles.reduce( (acc, file) => { acc[file.path] = file.content.length; return acc; }, {} as Record<string, number>, ), fileTokenCounts: processedFiles.reduce( (acc, file) => { acc[file.path] = file.content.split(/\s+/).length; return acc; }, {} as Record<string, number>, ), - suspiciousFilesResults: [], - suspiciousGitDiffResults: [], }; },tests/core/output/outputGenerateDiffs.test.ts (2)
150-158: LGTM: Markdown test updated to new signature.Consider adding a counterpart suite for git logs inclusion when enabled.
If output templates render a "Git Logs" section, introduce a test that sets gitLogResult and asserts presence of that section.
228-236: LGTM: No-diffs case updated to new signature.Mock still asserts absence of diffs; consider an analogous "no-logs" case as well for completeness.
src/core/packager.ts (1)
101-102: Gate the progress message on config to avoid confusing UXOnly show “Getting git logs...” when includeLogs is enabled to reduce noise for users who didn’t opt-in.
Apply this diff:
- progressCallback('Getting git logs...'); + if (config.output.git?.includeLogs) { + progressCallback('Getting git logs...'); + }src/core/security/validateFileSafety.ts (1)
37-44: Extract duplicated logging into a helper for maintainabilityBoth “git diffs” and “git logs” loops duplicate issue counting and formatting. Consider a tiny local helper to reduce repetition.
Example helper (outside the function or inline within):
function logSecurityIssueList(header: string, results: SuspiciousFileResult[]) { logger.warn(header); for (const result of results) { const issueCount = result.messages.length; const issueText = issueCount === 1 ? 'issue' : 'issues'; logger.warn(` - ${result.filePath}: ${issueCount} ${issueText} detected`); } }Then:
if (suspiciousGitDiffResults.length > 0) { logSecurityIssueList('Security issues found in Git diffs, but they will still be included in the output', suspiciousGitDiffResults); } if (suspiciousGitLogResults.length > 0) { logSecurityIssueList('Security issues found in Git logs, but they will still be included in the output', suspiciousGitLogResults); }Also applies to: 46-53
src/core/metrics/calculateGitLogMetrics.ts (1)
24-29: Treat whitespace-only content as emptyTrimming avoids counting tokens for all-whitespace content.
Apply this diff:
- if (!gitLogResult.logContent) { + if (!gitLogResult.logContent?.trim()) { return { gitLogTokenCount: 0, }; }src/config/configSchema.ts (1)
47-49: Consider stricter validation and a safe upper bound for includeLogsCountTo prevent excessive log retrieval and token usage, add int/min constraints to the base schema and a max bound to the default schema (e.g., 1000). This safeguards against accidental huge counts.
Apply these diffs:
Base schema:
- includeLogsCount: z.number().optional(), + includeLogsCount: z.number().int().min(1).optional(),Default schema:
- includeLogsCount: z.number().int().min(1).default(50), + includeLogsCount: z.number().int().min(1).max(1000).default(50),Also applies to: 108-110
src/cli/cliReport.ts (2)
67-78: Add Git Logs summary line (token count) for parity with Git DiffsSince PackResult exposes gitLogTokenCount and users can enable includeLogs, show a one-line summary similar to diffs.
Apply this diff after the Git Diffs block:
if (config.output.git?.includeDiffs) { let gitDiffsMessage = ''; if (packResult.gitDiffTokenCount) { gitDiffsMessage = pc.white( `✔ Git diffs included ${pc.dim(`(${packResult.gitDiffTokenCount.toLocaleString()} tokens)`)}`, ); } else { gitDiffsMessage = pc.dim('✖ No git diffs included'); } logger.log(`${pc.white(' Git Diffs:')} ${gitDiffsMessage}`); } + + if (config.output.git?.includeLogs) { + let gitLogsMessage = ''; + if (packResult.gitLogTokenCount) { + gitLogsMessage = pc.white( + `✔ Git logs included ${pc.dim(`(${packResult.gitLogTokenCount.toLocaleString()} tokens)`)}`, + ); + } else { + gitLogsMessage = pc.dim('✖ No git logs included'); + } + logger.log(`${pc.white(' Git Logs:')} ${gitLogsMessage}`); + }
80-86: Nit: parameter naming for clarityThe first parameter is labeled rootDir but the caller passes cwd. Consider renaming to cwd for consistency.
Apply this diff:
-export const reportSecurityCheck = ( - rootDir: string, +export const reportSecurityCheck = ( + cwd: string, suspiciousFilesResults: SuspiciousFileResult[], suspiciousGitDiffResults: SuspiciousFileResult[], suspiciousGitLogResults: SuspiciousFileResult[], config: RepomixConfigMerged, ) => { @@ - const relativeFilePath = path.relative(rootDir, suspiciousFilesResult.filePath); + const relativeFilePath = path.relative(cwd, suspiciousFilesResult.filePath);src/core/git/gitLogHandle.ts (3)
47-48: Respect explicit 0 and clamp includeLogsCount with nullish coalescingUsing
|| 50treats0as falsy and overrides it with 50. Prefer??to respect explicit 0 and optionally clamp to a sane range to avoid excessive output.Apply this diff:
- const maxCommits = config.output.git?.includeLogsCount || 50; + const maxCommitsRaw = config.output.git?.includeLogsCount; + // Clamp to a reasonable range to avoid huge outputs (tweak bounds as desired) + const maxCommits = Math.max(1, Math.min(500, maxCommitsRaw ?? 50));
48-52: Avoid emitting empty git logs block when content is emptyIf the repo root isn’t a Git repository or there are no logs,
logContentcan be empty. Emitting an empty block adds noise to output. Only set a result when content is non-empty.- const logContent = await deps.getGitLog(gitRoot, maxCommits); - - gitLogResult = { - logContent, - }; + const logContent = await deps.getGitLog(gitRoot, maxCommits); + if (logContent.trim().length > 0) { + gitLogResult = { + logContent, + }; + }
27-27: Log the full error object, not just.messagePassing only
error.messagedrops stack/context. If your logger formats objects, prefer logging the error itself.- logger.trace('Failed to get git log:', (error as Error).message); + logger.trace('Failed to get git log:', error);src/core/output/outputGenerate.ts (2)
92-96: Gate the XML git_logs block on non-empty contentAvoid emitting an empty
<git_logs/>section when logs are enabled but content is empty. This reduces noise in parsable outputs.- git_logs: renderContext.gitLogEnabled + git_logs: renderContext.gitLogEnabled && Boolean(renderContext.gitLogContent?.trim()) ? { git_log_content: renderContext.gitLogContent, } : undefined,
145-152: Mention git logs as a potential cause/remediation for oversized outputsIf logs are large, users benefit from guidance specific to
--include-logsand--include-logs-count.- throw new RepomixError( - `Output size exceeds JavaScript string limit. The repository contains files that are too large to process. -Please try: - - Use --ignore to exclude large files (e.g., --ignore "docs/**" or --ignore "*.html") - - Use --include to process only specific files - - Process smaller portions of the repository at a time${largeFilesInfo}`, - { cause: error }, - ); + throw new RepomixError( + `Output size exceeds JavaScript string limit. The repository contains files that are too large to process. +Please try: + - Use --ignore to exclude large files (e.g., --ignore "docs/**" or --ignore "*.html") + - Use --include to process only specific files + - Reduce Git logs: lower --include-logs-count (e.g., --include-logs-count 20) or disable --include-logs + - Process smaller portions of the repository at a time${largeFilesInfo}`, + { cause: error }, + );
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (37)
README.md(4 hunks)repomix.config.json(1 hunks)src/cli/actions/defaultAction.ts(1 hunks)src/cli/cliReport.ts(3 hunks)src/cli/cliRun.ts(1 hunks)src/cli/types.ts(1 hunks)src/config/configSchema.ts(2 hunks)src/core/git/gitCommand.ts(1 hunks)src/core/git/gitLogHandle.ts(1 hunks)src/core/metrics/calculateGitLogMetrics.ts(1 hunks)src/core/metrics/calculateMetrics.ts(6 hunks)src/core/metrics/workers/gitLogMetricsWorker.ts(1 hunks)src/core/output/outputGenerate.ts(7 hunks)src/core/output/outputGeneratorTypes.ts(3 hunks)src/core/output/outputStyleDecorate.ts(1 hunks)src/core/output/outputStyles/markdownStyle.ts(1 hunks)src/core/output/outputStyles/plainStyle.ts(1 hunks)src/core/output/outputStyles/xmlStyle.ts(1 hunks)src/core/packager.ts(6 hunks)src/core/security/securityCheck.ts(4 hunks)src/core/security/validateFileSafety.ts(4 hunks)src/core/security/workers/securityCheckWorker.ts(1 hunks)tests/cli/actions/defaultAction.test.ts(4 hunks)tests/cli/actions/remoteAction.test.ts(4 hunks)tests/cli/cliReport.test.ts(5 hunks)tests/cli/cliRun.test.ts(2 hunks)tests/config/configSchema.test.ts(2 hunks)tests/core/metrics/calculateMetrics.test.ts(1 hunks)tests/core/metrics/diffTokenCount.test.ts(3 hunks)tests/core/output/diffsInOutput.test.ts(2 hunks)tests/core/output/outputGenerate.test.ts(2 hunks)tests/core/output/outputGenerateDiffs.test.ts(5 hunks)tests/core/packager.test.ts(2 hunks)tests/core/security/securityCheck.test.ts(10 hunks)tests/core/security/validateFileSafety.test.ts(1 hunks)tests/integration-tests/packager.test.ts(1 hunks)tests/mcp/tools/packCodebaseTool.test.ts(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (19)
src/core/metrics/workers/gitLogMetricsWorker.ts (2)
src/shared/logger.ts (3)
setLogLevelByWorkerData(99-112)logger(89-89)error(34-38)src/core/metrics/tokenCounterFactory.ts (2)
getTokenCounter(12-19)freeTokenCounters(25-31)
src/core/output/outputGeneratorTypes.ts (1)
src/core/git/gitLogHandle.ts (1)
GitLogResult(7-9)
src/core/git/gitCommand.ts (1)
src/shared/logger.ts (2)
error(34-38)logger(89-89)
src/core/metrics/calculateGitLogMetrics.ts (4)
src/config/configSchema.ts (1)
RepomixConfigMerged(164-164)src/core/git/gitLogHandle.ts (1)
GitLogResult(7-9)src/core/metrics/workers/gitLogMetricsWorker.ts (2)
GitLogMetricsTask(9-12)GitLogMetricsTask(14-37)src/shared/logger.ts (2)
logger(89-89)error(34-38)
src/core/git/gitLogHandle.ts (3)
src/shared/logger.ts (2)
logger(89-89)error(34-38)src/config/configSchema.ts (1)
RepomixConfigMerged(164-164)src/shared/errorHandle.ts (1)
RepomixError(5-10)
tests/cli/cliReport.test.ts (1)
src/cli/cliReport.ts (1)
reportSecurityCheck(80-137)
tests/core/output/diffsInOutput.test.ts (1)
src/core/output/outputGenerate.ts (1)
generateOutput(161-197)
tests/core/security/validateFileSafety.test.ts (1)
src/core/security/validateFileSafety.ts (1)
validateFileSafety(13-67)
src/core/security/securityCheck.ts (2)
src/core/git/gitLogHandle.ts (1)
GitLogResult(7-9)src/core/security/workers/securityCheckWorker.ts (3)
SuspiciousFileResult(19-23)SecurityCheckTask(13-17)SecurityCheckTask(25-42)
tests/core/output/outputGenerate.test.ts (1)
src/core/output/outputGenerate.ts (1)
generateOutput(161-197)
tests/integration-tests/packager.test.ts (1)
src/core/security/validateFileSafety.ts (1)
validateFileSafety(13-67)
src/core/security/validateFileSafety.ts (2)
src/core/git/gitLogHandle.ts (1)
GitLogResult(7-9)src/core/security/securityCheck.ts (1)
SuspiciousFileResult(10-14)
tests/core/security/securityCheck.test.ts (1)
src/core/security/securityCheck.ts (1)
runSecurityCheck(16-104)
src/cli/cliReport.ts (2)
src/core/security/securityCheck.ts (1)
SuspiciousFileResult(10-14)src/core/security/workers/securityCheckWorker.ts (1)
SuspiciousFileResult(19-23)
tests/core/output/outputGenerateDiffs.test.ts (1)
src/core/output/outputGenerate.ts (1)
generateOutput(161-197)
src/core/metrics/calculateMetrics.ts (1)
src/core/git/gitLogHandle.ts (1)
GitLogResult(7-9)
src/core/output/outputGenerate.ts (1)
src/core/git/gitLogHandle.ts (1)
GitLogResult(7-9)
src/core/packager.ts (3)
src/core/security/securityCheck.ts (1)
SuspiciousFileResult(10-14)src/core/security/workers/securityCheckWorker.ts (1)
SuspiciousFileResult(19-23)src/shared/memoryUtils.ts (1)
withMemoryLogging(71-87)
tests/core/metrics/calculateMetrics.test.ts (3)
tests/testing/testUtils.ts (1)
createMockConfig(15-45)src/core/git/gitDiffHandle.ts (1)
GitDiffResult(7-10)src/core/metrics/calculateMetrics.ts (1)
calculateMetrics(21-88)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
- GitHub Check: Test (windows-latest, 23.x)
- GitHub Check: Test (macos-latest, 23.x)
- GitHub Check: Test (windows-latest, 20.x)
- GitHub Check: Test (windows-latest, 22.x)
- GitHub Check: Test (windows-latest, 24.x)
- GitHub Check: Test (windows-latest, 21.x)
- GitHub Check: Test coverage
🔇 Additional comments (54)
src/core/security/workers/securityCheckWorker.ts (1)
10-11: 'gitLog' type support added — LGTMExpanding SecurityCheckType to include 'gitLog' cleanly aligns with the new pipeline. No runtime impact here; downstream code can now discriminate on the new type.
README.md (1)
990-993: Example config — LGTMDefaults align with the schema and CLI docs.
src/core/metrics/workers/gitLogMetricsWorker.ts (1)
1-37: Worker implementation looks solid
- Logger level is initialized before logging.
- Safe error handling with 0 fallback.
- Finally block frees counters to avoid leaks.
src/cli/types.ts (1)
27-28: CLI types extended — LGTMThe additions match the new flags and config surface and follow existing naming conventions.
src/core/output/outputStyleDecorate.ts (1)
187-191: LGTM: Clear, user-facing note for Git logs inclusionThe summary note reads well and aligns with the new CLI/config surface.
tests/cli/actions/remoteAction.test.ts (1)
48-53: LGTM: Tests correctly updated for new PackResult fieldsEach scenario includes
suspiciousGitLogResultsandgitLogTokenCount, keeping test fixtures aligned with the extended PackResult type. Good use ofsatisfies DefaultActionRunnerResultto catch shape mismatches at compile-time.Also applies to: 90-95, 135-140, 180-185
tests/mcp/tools/packCodebaseTool.test.ts (1)
42-45: LGTM: Default pack result extended with Git log fields
gitLogTokenCountandsuspiciousGitLogResultsare added in step with the new pipeline data, keeping tool tests consistent with the updated PackResult contract.repomix.config.json (1)
26-29: LGTM: Config exposes Git logs and count
includeLogsandincludeLogsCountare clearly surfaced and consistent with the CLI options and schema changes described in the PR.tests/config/configSchema.test.ts (2)
121-123: Defaults for includeLogs and includeLogsCount look correctValidating the default schema with includeLogs: false and includeLogsCount: 50 matches the PR spec. No issues.
219-221: Merged schema test updates are consistentThe merged schema fixture correctly includes includeLogs and includeLogsCount fields under output.git. LGTM.
src/core/output/outputGeneratorTypes.ts (2)
4-4: Type import for GitLogResult correctly threads log dataImporting GitLogResult from gitLogHandle and surfacing it through the context is consistent with the existing GitDiff types.
13-14: RenderContext additions are coherent and minimalAdding gitLogEnabled and gitLogContent mirrors the git diff pattern and keeps templates decoupled. Looks good.
tests/core/packager.test.ts (1)
82-88: Updated dependency call signatures: LGTM.Expectations now reflect the optional git log params (undefined placeholders) for validateFileSafety, generateOutput, and calculateMetrics. This matches the broader API changes.
Also applies to: 97-97, 106-107
tests/core/output/diffsInOutput.test.ts (1)
126-131: Switched to 7-arg generateOutput call — consistent with new gitLogResult param (LGTM)Passing
undefinedas the 6th arg correctly occupies the newgitLogResultslot. Deps object remains last. Looks good.Also applies to: 189-194
tests/core/security/validateFileSafety.test.ts (1)
28-31: Updated signature usage and expectations — LGTM
- Passing the extra
undefinedarg to occupygitLogResultaligns with the new API.- Expecting
runSecurityCheckto be called with four args and assertingsuspiciousGitLogResults: []is correct for the no-logs case.Also applies to: 37-38
tests/core/output/outputGenerate.test.ts (1)
43-51: Adaptation to new generateOutput/buildOutputGeneratorContext signatures — LGTM
- The added 6th
undefinedparameter occupiesgitLogResult.- The expectation now correctly includes both
gitDiffResultandgitLogResultasundefined.Also applies to: 60-61
tests/core/security/securityCheck.test.ts (1)
55-57: Calls updated for new runSecurityCheck parameter order — LGTMAll updated invocations correctly pass the extra
undefinedforgitLogResultbefore the deps object. The diff-related tests still behave as intended.Also applies to: 67-69, 93-95, 103-105, 111-113, 121-123, 135-137, 161-163, 183-185, 203-205, 223-225
tests/core/metrics/calculateMetrics.test.ts (1)
51-52: Metrics updated to include gitLogTokenCount — LGTM
- The expected aggregate includes
gitLogTokenCount: 0.- The deps now expose
calculateGitLogMetricsreturning{ gitLogTokenCount }, matching production return shape.Also applies to: 58-63
src/core/security/securityCheck.ts (5)
7-7: LGTM: correct type import for GitLogResult.Import is aligned with the new data flow for git logs.
20-24: API surface widened; verify all callers updated.Signature adds gitLogResult before deps. Tests and validateFileSafety show correct adoption. Keep this parameter order consistent across the codebase.
If any internal callers still use the old 4-arg form, TypeScript should flag them. Run a quick repo-wide check for
runSecurityCheck(call arity mismatches.
26-26: LGTM: dedicated container for gitLog tasks.Keeps concerns separated and simplifies counting and orchestration.
47-56: Good guarded addition of Git log scanning; consider upstream size bounds.Task creation is correctly gated. Ensure upstream git log collection caps size/entry count to avoid excessive scanning time or token inflation (PR mentions default 50, which sounds good).
Would you confirm getGitLogs/getGitLogResult already enforce count and sanitize content (e.g., strip ANSI, exclude hashes as per spec)?
71-73: LGTM: unified task list includes files, diffs, and logs.Ordering is consistent with prior behavior; progress messages will be intuitive.
tests/cli/cliReport.test.ts (3)
61-74: LGTM: summary test updated to include git logs fields with zero counts.Keeps test realistic while not engaging logs path.
88-89: LGTM: reportSecurityCheck call updated to 5-arg signature.Matches src/cli/cliReport.ts.
117-118: LGTM: call updated for new parameter order.Maintains test intent; no behavior change.
src/core/metrics/calculateMetrics.ts (5)
5-5: LGTM: GitLogResult type import added.Aligns with new metrics pathway.
7-8: LGTM: calculateGitLogMetrics dependency wired in.Keeps metrics modular and symmetric with git-diff metrics.
18-19: LGTM: CalculateMetricsResult extended with gitLogTokenCount.Public API change is clear.
27-33: LGTM: Function signature extended to accept gitLogResult and deps.Ensure all callsites were updated; integration tests reflect this.
86-87: LGTM: returning gitLogTokenCount from metrics.Completes the surface area update.
tests/integration-tests/packager.test.ts (1)
127-131: LGTM: validateFileSafety call updated with gitLogResult slot.Passing undefined adheres to the widened signature and keeps behavior unchanged.
tests/core/output/outputGenerateDiffs.test.ts (3)
83-90: LGTM: generateOutput call updated for new gitLogResult parameter.Maintains prior behavior by passing undefined.
116-124: LGTM: 7-arg form used consistently (parsable XML test).No behavior change; placeholder args are correct.
184-192: LGTM: Plain output test updated to new signature.Stable behavior with undefined gitLogResult.
src/core/packager.ts (5)
26-29: PackResult shape extension looks consistentAdding gitLogTokenCount and suspiciousGitLogResults aligns with the new feature and downstream consumers (metrics, CLI reporting).
45-46: Dependency injection extended correctlyIncluding getGitLogs in defaultDeps enables easy test overrides and maintains symmetry with getGitDiffs.
105-108: Good: security checks now handle git logsvalidateFileSafety gets gitLogResult and returns suspiciousGitLogResults, keeping parity with git diffs.
118-119: Output and metrics wiring LGTMPropagating gitLogResult into generateOutput and calculateMetrics is correct and keeps the pipeline cohesive.
Also applies to: 127-128
135-136: Result aggregation updated appropriatelyIncluding suspiciousGitLogResults in the final result ensures CLI/reporters can surface issues.
src/core/security/validateFileSafety.ts (3)
6-6: Signature and types updated correctlyAdding GitLogResult to the params and types cleanly threads logs through the validator.
Also applies to: 18-19
32-36: Clean separation of result typesFiltering by result.type into file/diff/log buckets is straightforward and readable.
46-53: Clear logging for Git log issuesMirrors the Git diff reporting, which is consistent and helpful for users.
src/core/metrics/calculateGitLogMetrics.ts (3)
17-23: Early exit conditions are solidCorrectly returning zero when logs are disabled or missing avoids unnecessary worker startup.
58-59: Proper cleanupAlways cleaning up the task runner avoids worker leaks.
31-34: Consistent worker module path format confirmedAll existing
initTaskRunnercalls acrosssrc/coreusenew URL(..., import.meta.url).hreffor worker paths. No discrepancies found—no changes needed.src/config/configSchema.ts (2)
47-49: New git fields added to base schema as optional — OKincludeLogs and includeLogsCount are correctly introduced and optional here.
108-110: Defaults added appropriatelyDefaults for includeLogs (false) and includeLogsCount (50) mirror the CLI behavior described in the PR.
src/cli/cliReport.ts (2)
30-36: Wiring suspicious Git log results into reporting — goodForwarding suspiciousGitLogResults into the report function completes the security reporting chain.
124-136: Git logs security reporting mirrors diffs — niceClear, consistent messaging that logs with issues are still included and should be reviewed.
src/core/git/gitLogHandle.ts (2)
11-23: Good DI and early exit designNice use of dependency injection and a quick exit when the directory isn’t a Git repo. This makes the unit tests straightforward and avoids unnecessary subprocess calls.
19-21: RepomixLogger.trace is available with a variadic signature
The methodtrace(...args: unknown[])is defined insrc/shared/logger.ts(around line 76) and supports variadic arguments, matching the usage in this module.src/core/output/outputGenerate.ts (2)
54-56: Clean propagation of git log state into RenderContextPlumbing
gitLogEnabledandgitLogContentthrough the render context is clear and keeps concerns separated. LGTM.
161-186: End-to-end threading of gitLogResult through generation pipeline looks solidThe additional parameter to
generateOutputand its handoff tobuildOutputGeneratorContextis consistent with how diffs are threaded. Nice, minimal surface area changes.
This feature allows users to include git log information in the output to help AI understand development patterns and file change relationships. Key changes: - Added --include-logs and --include-logs-count CLI options - Default to 50 commits, configurable via CLI and config file - Includes commit date, message, and changed file paths (excludes commit hashes) - Added security checks and metrics calculation for git logs - Updated output templates to include git logs section - Comprehensive test coverage and TypeScript fixes Resolves user request for including git commit history to provide development context for AI analysis.
- Add GitLogCommit interface with structured date, message, and files - Parse raw git log output into structured commits array - Update output templates to render each commit separately: - XML: Use <git_log_commit> tags for each commit - Markdown: Use separate sections with commit headers - Plain: Use separator lines between commits - Improve readability and AI parsing of git log data
- Add CLI options --include-logs and --include-logs-count to all guides - Add configuration options includeLogs and includeLogsCount - Add output examples for XML, Markdown, and Plain text formats - Add Git Integration usage examples - Update English (en), Japanese (ja), and Chinese (zh-cn) documentation - Use structured git log output examples matching current implementation Updated files: - command-line-options.md: CLI flag documentation - configuration.md: Config schema and examples - output.md: Format-specific output examples - usage.md: Git integration usage patterns
- Complete Chinese (zh-cn) documentation: - configuration.md: Add config options and Git integration section - output.md: Add structured output examples for all formats - usage.md: Add Git integration usage patterns - Add Korean (ko) basic CLI options documentation: - command-line-options.md: Add --include-logs and --include-logs-count All major Asian languages now have --include-logs documentation: - Japanese (ja): Complete 4-file update - Chinese (zh-cn): Complete 4-file update - Korean (ko): Basic CLI options added Total languages updated: 4 (en, ja, zh-cn, ko) Total files updated: 13 files across multiple languages
- configuration.md: Add config options table and Git integration section - output.md: Add structured output examples for XML, Markdown, and Plain formats - usage.md: Add Git integration usage patterns and examples Korean documentation now complete with all 4 files updated: - command-line-options.md: CLI options (previously completed) - configuration.md: Config schema and examples - output.md: Format-specific structured examples - usage.md: Git integration patterns Major Asian languages now have complete --include-logs documentation: - English (en): 4 files - Japanese (ja): 4 files - Chinese (zh-cn): 4 files - Korean (ko): 4 files Total: 16 files across 4 major languages with comprehensive coverage
…g languages Updated 8 languages with comprehensive --include-logs documentation: - German (de): 4 files - CLI options, config, output examples, Git integration - Spanish (es): 4 files - CLI options, config, output examples, Git integration - French (fr): 4 files - CLI options, config, output examples, Git integration - Hindi (hi): 4 files - CLI options, config, output examples, Git integration - Indonesian (id): 4 files - CLI options, config, output examples, Git integration - Portuguese (pt-br): 4 files - CLI options, config, output examples, Git integration - Vietnamese (vi): 4 files - CLI options, config, output examples, Git integration - Chinese Traditional (zh-tw): 4 files - CLI options, config, output examples, Git integration Each language now includes: - --include-logs and --include-logs-count CLI options with proper translations - includeLogs and includeLogsCount configuration options - Structured git log output examples for XML/Markdown/Plain formats - Git Integration usage sections with development context explanations - Real commit examples from 2025-08-20 and 2025-08-21 - XML structured format with <git_log_commit> tags Total: 32 additional files across 8 languages Combined with previous updates: 48 files across 12 languages (en, ja, zh-cn, ko, de, es, fr, hi, id, pt-br, vi, zh-tw) All major world languages now have complete --include-logs feature documentation.
2ad66cf to
4f8e03d
Compare
|
@claude review |
|
/gemini review |
|
@coderabbitai review |
There was a problem hiding this comment.
Pull Request Overview
This PR adds a new --include-logs feature that allows users to include Git commit history in the output to help AI understand development patterns and file change relationships.
Key Changes
- Added
--include-logsCLI flag and--include-logs-countto specify number of commits (default: 50) - Added configuration support for
includeLogsandincludeLogsCountin config schema - Extended output generation to include Git logs section across all output styles (XML, Markdown, Plain)
Reviewed Changes
Copilot reviewed 85 out of 85 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| Website documentation files | Updates all language versions of documentation to describe the new Git logs feature |
| Test files | Updates to accommodate new function signatures and parameters for Git logs handling |
| Core implementation files | Adds Git log processing, metrics calculation, and security checking for log content |
| Configuration and CLI files | Adds new options for Git logs in configuration schema and CLI interface |
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Code Review
This pull request introduces a valuable new feature to include git commit history in the output, which will significantly enhance the context provided to AI models. The implementation is comprehensive, covering CLI options, configuration, core logic, security checks, metrics, and documentation across multiple languages. The code is well-structured and the changes are logically organized.
I have a few suggestions to improve robustness and maintainability. One key suggestion is to use a more reliable method for parsing git log output to avoid potential issues with special characters in commit messages. I've also identified a bug in the XML template generation that could lead to malformed output, and proposed a refactoring to simplify the CLI option handling.
Overall, this is an excellent contribution that is well on its way to being merged.
There was a problem hiding this comment.
Actionable comments posted: 8
♻️ Duplicate comments (3)
src/core/output/outputStyles/plainStyle.ts (1)
80-97: LGTM: Plain-text Git Logs block renders cleanly and fixes prior${...}escaping issueThe section uses unescaped template placeholders correctly (
${PLAIN_*}without backslashes) and clear separators around each commit. Matches the rest of the plain style.src/cli/cliReport.ts (1)
124-136: DRY up duplicated reporting logic; also format counts consistentlyThe new Git logs block mirrors the Git diffs block almost verbatim. Extract a small helper to render “suspicious group” sections and call it for files/diffs/logs. Also, for consistency with other counts (e.g., summary), consider toLocaleString() for the Git logs count.
Apply this small consistency tweak:
- logger.log(pc.yellow(`${suspiciousGitLogResults.length} security issue(s) found in Git logs:`)); + logger.log(pc.yellow(`${suspiciousGitLogResults.length.toLocaleString()} security issue(s) found in Git logs:`));Example helper to reduce duplication (illustrative; add outside this block and call from each section):
function reportSuspiciousGroup( title: string, items: SuspiciousFileResult[], renderPath: (i: number, r: SuspiciousFileResult) => string, notes: string[], ) { if (items.length === 0) return; logger.log(''); logger.log(pc.yellow(`${items.length.toLocaleString()} ${title}`)); items.forEach((r, idx) => { logger.log(`${pc.white(`${idx + 1}.`)} ${pc.white(renderPath(idx, r))}`); const c = r.messages.length; logger.log(pc.dim(` - ${c} ${c === 1 ? 'security issue' : 'security issues'} detected`)); }); notes.forEach((n) => logger.log(pc.yellow(n))); }src/core/git/gitLogHandle.ts (1)
97-101: Always rethrow with context; don’t swallow non-Error throwsCurrent catch only rethrows for Error instances; other thrown values get silently ignored, hiding failures. Rewrap everything with RepomixError and preserve cause.
- } catch (error) { - if (error instanceof Error) { - throw new RepomixError(`Failed to get git logs: ${error.message}`); - } - } + } catch (error) { + throw new RepomixError( + `Failed to get git logs: ${error instanceof Error ? error.message : String(error)}`, + error instanceof Error ? { cause: error } : undefined, + ); + }
🧹 Nitpick comments (86)
website/client/src/id/guide/configuration.md (3)
42-43: Clarify behavior (no hashes), capitalize “Git”, and note token-size impact.Suggest tightening the phrasing and aligning capitalization. Also explicitly state that commit hashes are excluded (as per the PR) and warn about larger output/token cost.
Apply this diff:
-| `output.git.includeLogs` | Apakah akan menyertakan log git dalam output. Menampilkan riwayat commit dengan tanggal, pesan, dan jalur file | `false` | -| `output.git.includeLogsCount` | Jumlah commit log git yang akan disertakan dalam output | `50` | +| `output.git.includeLogs` | Apakah akan menyertakan log Git dalam output. Menampilkan riwayat commit dengan tanggal (ISO), pesan, dan jalur file per commit; hash commit tidak disertakan. Perhatikan: fitur ini menambah ukuran output dan jumlah token. | `false` | +| `output.git.includeLogsCount` | Jumlah commit terbaru yang akan disertakan pada log Git di output | `50` |
193-195: Document CLI parity and “no hashes”; fix “git” → “Git”.Add a brief note showing the equivalent CLI flags and that commit hashes are intentionally excluded. This reduces ambiguity for users switching between CLI and config.
- If there’s a maximum cap or validation for
includeLogsCountin the schema (e.g., min/max), consider documenting it here.Apply this diff:
-- `includeLogs`: Ketika true, menyertakan riwayat commit Git dalam output. Menampilkan tanggal commit, pesan, dan jalur file untuk setiap commit. Ini membantu AI memahami pola pengembangan dan hubungan file. Default: `false` -- `includeLogsCount`: Jumlah commit terbaru yang akan disertakan dalam log git. Default: `50` +- `includeLogs`: Ketika true, menyertakan riwayat commit Git dalam output. Menampilkan tanggal commit (ISO), pesan, dan jalur file untuk setiap commit; hash commit tidak disertakan. Dapat juga diatur via CLI: `--include-logs`. Ini membantu AI memahami pola pengembangan dan hubungan file. Default: `false` +- `includeLogsCount`: Jumlah commit terbaru yang akan disertakan dalam log Git. Dapat juga diatur via CLI: `--include-logs-count <n>`. Default: `50`
203-206: Minor UX note: call out potential size growth when enabling both diffs and logs.The example rightly shows both enabled; consider adding a short warning sentence above/below the block (outside the JSON) that enabling
includeDiffsandincludeLogstogether can significantly increase output size and token usage.website/client/src/es/guide/usage.md (5)
96-112: Good addition; propose minor Spanish/consistency polish in intro and examplesTighten the intro sentence and capitalize “Git” consistently in inline comments. Also prefer “predeterminado” to match the rest of the doc (e.g., “XML (predeterminado)”) instead of “por defecto”.
Apply:
-Incluye información de Git para proporcionar contexto de desarrollo al análisis de IA: +Incluye información de Git para aportar contexto de desarrollo al análisis con IA. -# Incluir diffs de git (cambios sin commit) +# Incluir diffs de Git (cambios no confirmados) -# Incluir logs de commits de git (últimos 50 commits por defecto) -# Incluir número específico de commits +# Incluir logs de commits de Git (últimos 50 commits de forma predeterminada) +# Incluir un número específico de commits
114-119: Refine bullet wording for clarity and agreementImprove tone and agreement; avoid Spanglish (“diffs”, “commit”) in descriptive text while keeping CLI flags as-is.
-Esto añade contexto valioso sobre: -- **Cambios recientes**: Los diffs de Git muestran modificaciones sin commit -- **Patrones de desarrollo**: Los logs de Git revelan qué archivos típicamente se cambian juntos -- **Historial de commits**: Los mensajes de commit recientes proporcionan información sobre el enfoque de desarrollo -- **Relaciones entre archivos**: Entender qué archivos se modifican en los mismos commits +Esto añade contexto valioso sobre: +- **Cambios recientes**: Las diferencias de Git muestran modificaciones no confirmadas +- **Patrones de desarrollo**: Los registros de Git revelan qué archivos suelen modificarse juntos +- **Historial de commits**: Los mensajes de commits recientes ofrecen pistas sobre el enfoque de desarrollo +- **Relaciones entre archivos**: Comprender qué archivos se modifican en los mismos commits
112-114: Add a short note about defaults, security checks, hashes, and token impactHelpful context aligned with the PR: hashes are excluded; default count is 50; security checks exist; logs can increase tokens.
-Esto añade contexto valioso sobre:
+> [!NOTE]
+> - Los hashes de commit no se incluyen en los logs.
+> - Controla la cantidad con--include-logs-count(predeterminado: 50) o desderepomix.config.jsonusandoincludeLogseincludeLogsCount.
+> - Los logs pasan por verificaciones de seguridad; puedes desactivarlas con--no-security-checksi sabes lo que haces.
+> - Incluir logs puede aumentar el tamaño de salida; usa--token-count-treepara evaluar el impacto.
+
+Esto añade contexto valioso sobre:Please confirm these bullets match the actual behavior: hashes excluded, default count 50, and that security checks cover git log content as implemented. --- `98-98`: **Address LanguageTool punctuation hint** LanguageTool flagged punctuation on this line. The rephrasing in my first suggestion (“…al análisis con IA.”) removes the trailing colon before the code block, which resolves the hint. --- `116-116`: **Fix agreement issue flagged by LanguageTool** Replacing “típicamente se cambian” with “suelen modificarse” (as suggested above) resolves the agreement inconsistency. </blockquote></details> <details> <summary>website/client/src/de/guide/usage.md (5)</summary><blockquote> `96-99`: **Polish heading copy for smoother German** Suggestion: “Git-Informationen einbinden, um Entwicklungskontext für KI‑Analysen bereitzustellen:” reads more natural than “einschließen”. Apply: ```diff - Git-Informationen einschließen, um Entwicklungskontext für KI-Analysen bereitzustellen: + Git-Informationen einbinden, um Entwicklungskontext für KI-Analysen bereitzustellen:
101-103: Use the correct Git terminology (not “ungespeicherte Änderungen”)“Ungespeicherte Änderungen” suggests unsaved editor buffers. For Git diffs, “nicht committete Änderungen (Arbeitsverzeichnis)” is the idiomatic phrasing.
Apply:
-# Git-Diffs einschließen (ungespeicherte Änderungen) +# Git-Diffs einschließen (nicht committete Änderungen im Arbeitsverzeichnis)Verification: If
--include-diffsalso covers staged changes, consider “nicht committete (staged und unstaged) Änderungen im Arbeitsverzeichnis”.
107-112: Cross‑reference config keys for discoverabilityMention that these flags are configurable (includeLogs, includeLogsCount) to align CLI and config docs.
Apply:
# Bestimmte Anzahl von Commits einschließen repomix --include-logs --include-logs-count 10 # Sowohl Diffs als auch Logs einschließen repomix --include-diffs --include-logs
+Diese Optionen lassen sich auch in der Konfiguration setzen
+(includeLogs,includeLogsCount).--- `113-113`: **Add privacy/security note matching implementation** Per the PR, commit Hashes are intentionally excluded; dates are ISO. Call this out to set expectations and reassure users. Apply: ```diff - +> [!NOTE] +> Aus Datenschutz-/Sicherheitsgründen werden bei Git-Logs keine Commit‑Hashes ausgegeben. +> Enthalten sind Datum (ISO‑Format), Commit‑Nachricht und geänderte Dateipfade.
114-119: Tighten bullet wording and fix “ungespeicherte Modifikationen”
- Replace “ungespeicherte Modifikationen” as above.
- “Aktuelle Commit‑Nachrichten” → “Neueste Commit‑Nachrichten” reads cleaner.
Apply:
- **Letzte Änderungen**: Git-Diffs zeigen ungespeicherte Modifikationen + - **Letzte Änderungen**: Git-Diffs zeigen nicht committete Änderungen im Arbeitsverzeichnis - **Entwicklungsmuster**: Git-Logs zeigen, welche Dateien typischerweise zusammen geändert werden - - **Commit-Historie**: Aktuelle Commit-Nachrichten geben Einblick in den Entwicklungsfokus + - **Commit-Historie**: Neueste Commit-Nachrichten geben Einblick in den Entwicklungsfokus - **Dateibeziehungen**: Verstehen, welche Dateien in denselben Commits modifiziert werdenwebsite/client/src/vi/guide/usage.md (3)
191-196: Add a quick note on what Git logs include/exclude, token impact, and security scan tie-in.Per the PR, hashes are excluded and logs pass security checks. Make this explicit and warn about token growth.
Apply this diff right after the bullet list:
- **Mối quan hệ tệp**: Hiểu tệp nào được sửa đổi trong cùng một commit + +> [!NOTE] +> - Phạm vi nhật ký: bao gồm ngày commit (ISO), thông điệp commit, và các đường dẫn tệp được thay đổi cho mỗi commit. +> - Không bao gồm: hash commit (để giảm rủi ro rò rỉ định danh). +> - Ảnh hưởng token: thêm logs có thể tăng kích thước đầu ra đáng kể — dùng `--include-logs-count` để giới hạn. +> - Bảo mật: nội dung nhật ký sẽ được quét bởi các kiểm tra bảo mật (có thể tắt với `--no-security-check` nếu bạn hiểu rủi ro).
184-186: Minor wording polish for clarity.“Bao gồm số lượng commit cụ thể” nghe hơi lạ; đề xuất “Giới hạn số lượng commit hiển thị” để tự nhiên hơn.
-# Bao gồm số lượng commit cụ thể +# Giới hạn số lượng commit hiển thị repomix --include-logs --include-logs-count 10
173-196: Add JSON configuration example for Git logs in Vietnamese usage guideTo improve discoverability and keep the CLI and config docs in sync, let’s show the equivalent
output.git.includeLogs*keys right after the CLI examples.• File:
website/client/src/vi/guide/usage.md
• After the “Bao gồm cả diff và logs” bash block### Tích hợp Git Bao gồm thông tin Git để cung cấp ngữ cảnh phát triển cho phân tích AI: ```bash # Bao gồm cả diff và logs repomix --include-diffs --include-logs
+Bạn cũng có thể cấu hình qua tệp cấu hình:
+
+```json
+{
- "output": {
- "git": {
"includeLogs": true,"includeLogsCount": 10- }
- }
+}
+```This reflects the actual config keys (`output.git.includeLogs`, `output.git.includeLogsCount`) wired in code (`configSchema.ts`, `types.ts`, `defaultAction.ts`). </blockquote></details> <details> <summary>website/client/src/fr/guide/configuration.md (4)</summary><blockquote> `42-43`: **Clarify wording, capitalize “Git”, and mention hashes exclusion** - Use “Git” consistently as a proper noun. - Slightly tighten the phrasing for includeLogsCount. - Explicitly state that commit hashes are excluded (as per PR objective), which is useful for privacy expectations. Apply this diff: ```diff -| `output.git.includeLogs` | Indique s'il faut inclure les journaux git dans la sortie. Montre l'historique des commits avec les dates, les messages et les chemins de fichiers | `false` | -| `output.git.includeLogsCount` | Nombre de commits de journaux git récents à inclure dans la sortie | `50` | +| `output.git.includeLogs` | Indique s'il faut inclure les journaux Git dans la sortie. Affiche les dates de commit, les messages et les chemins de fichiers (sans les hachages de commit) | `false` | +| `output.git.includeLogsCount` | Nombre de commits récents à inclure dans les journaux Git | `50` |Additionally, double‑check table rendering: some linters flagged a potential extra “|” before this row. If you see any misalignment in preview, remove any stray pipe characters at row boundaries.
193-195: Improve consistency and add privacy note; reduce repetition of “Lorsque vrai”
- Align capitalization of “Git”.
- Add a short note that commit hashes are excluded.
- Minor style tweak to avoid repetitive “Lorsque vrai”.
Apply this diff:
-- `includeLogs` : Lorsque vrai, inclut l'historique des commits Git dans la sortie. Montre les dates des commits, les messages et les chemins de fichiers pour chaque commit. Cela aide l'IA à comprendre les modèles de développement et les relations entre fichiers. Par défaut : `false` -- `includeLogsCount` : Le nombre de commits récents à inclure dans les journaux git. Par défaut : `50` +- `includeLogs` : Si activé, inclut l'historique des commits Git dans la sortie. Affiche les dates, les messages et les chemins de fichiers (les hachages de commit sont exclus). Aide l'IA à comprendre les modèles de développement et les relations entre fichiers. Par défaut : `false` +- `includeLogsCount` : Nombre de commits récents à inclure dans les journaux Git. Par défaut : `50`
203-206: Example config matches intended usageThe example correctly demonstrates enabling both diffs and logs with a reduced includeLogsCount (25). Consider adding a brief note in prose above/below the example that larger values will increase token usage and runtime, so users should tune this per repository size.
Happy to draft a one‑liner guidance note about performance/token impact if you want it included here.
42-43: Refactor: Standardize “Git” Capitalization Across All Localized DocsI ran the consistency check script and found several instances of lowercase “git” in our localized markdown files—including the French configuration guide. To keep terminology uniform and align with the official “Git” branding, please update these occurrences to uppercase “Git.”
• In
website/client/src/fr/guide/configuration.md:
– Lines 42–43 (and also 193–195) change “git” → “Git” in the descriptions foroutput.git.includeLogsandoutput.git.includeLogsCount.
• Similar lowercase “git” occurrences exist in other locales underwebsite/client/src/*/guide/…; consider running the provided ripgrep command to locate and correct them project-wide.To preview the French docs locally, use one of the following npm scripts defined in
package.json:npm run website # boots the docs via Docker Compose npm run repomix-website # runs the repomix preview toolEnsuring consistent “Git” capitalization will improve the professionalism and clarity of our documentation.
website/client/src/fr/guide/command-line-options.md (2)
31-32: Clarify behavior (exclude hashes) and localize placeholder.The bullets read well. Two tweaks improve precision and FR consistency:
- Make explicit that commit hashes are excluded (feature guarantee).
- Localize the placeholder
<count>to<nombre>and simplify the phrasing.- - `--include-logs`: Inclure les journaux git dans la sortie (inclut l'historique des commits avec les dates, les messages et les chemins de fichiers) - - `--include-logs-count <count>`: Nombre de commits de journaux git à inclure (par défaut : 50) + - `--include-logs`: Inclure les journaux git dans la sortie (historique des commits avec dates au format ISO 8601, messages et chemins de fichiers; sans hash de commit) + - `--include-logs-count <nombre>`: Nombre de commits à inclure dans l'historique git (par défaut : 50)
92-97: Align example comments with earlier option description.The include-diffs comment narrows scope to “modifications non commitées” only, whereas the option bullet above states it includes working tree and staged changes separately. Also mirror the “no hashes” guarantee for logs in examples.
- repomix --include-diffs # Inclure les diffs git pour les modifications non commitées + repomix --include-diffs # Inclure les diffs git (modifications de l'arbre de travail et indexées, séparées) - repomix --include-logs # Inclure les journaux git (derniers 50 commits par défaut) + repomix --include-logs # Inclure les journaux git (50 derniers commits par défaut; sans hash de commit) repomix --include-logs --include-logs-count 10 # Inclure les 10 derniers commits repomix --include-diffs --include-logs # Inclure à la fois les diffs et les journauxwebsite/client/src/ko/guide/configuration.md (2)
193-195: Strengthen the guidance: add security/hash notes and token/perf caveat.
- Call out that commit hashes are excluded and logs pass through security checks.
- Briefly warn about token size and runtime impact when enabling logs.
Apply:
-- `includeLogs`: true로 설정하면 Git 로그를 출력에 포함합니다. 커밋 히스토리의 날짜, 메시지, 파일 경로가 표시되어 AI가 어떤 파일들이 일반적으로 함께 변경되는지 이해할 수 있습니다. 기본값: `false` -`includeLogsCount`: 포함할 Git 로그 커밋 수입니다. 개발 패턴 분석에 사용되는 히스토리 깊이를 제어합니다. 기본값: `50` +- `includeLogs`: true로 설정하면 Git 로그를 출력에 포함합니다. 커밋 이력의 날짜, 메시지, 파일 경로가 표시되어 AI가 어떤 파일들이 일반적으로 함께 변경되는지 이해할 수 있습니다. 커밋 해시는 포함하지 않습니다. 기본값: `false` +- `includeLogsCount`: 포함할 Git 로그 커밋 수입니다. 개발 패턴 분석에 사용되는 이력 깊이를 제어합니다. 기본값: `50` + - 참고: 로그는 보안 검사(Secretlint)를 통과하며, 로그 포함은 토큰 수와 실행 시간에 영향을 줄 수 있습니다.
203-206: Example is consistent; optional clarification on intent of “30”.The JSON is valid and matches the new options. If you want to preempt questions, add a short sentence above the block like “아래 예시는 최근 30개 커밋의 로그를 포함합니다.” (but the current version is acceptable as-is).
website/client/src/ja/guide/configuration.md (4)
42-43: Clarify format and privacy constraints for Git logs.Spell out the timestamp format and explicitly note that commit hashes are excluded to avoid confusion and set privacy expectations.
Apply this diff to tighten the wording:
-| `output.git.includeLogs` | 出力にGitログを含めるかどうか。コミット履歴の日時、メッセージ、ファイルパスを表示します | `false` | +| `output.git.includeLogs` | 出力にGitログを含めるかどうか。コミット履歴の日時(ISO 8601)、メッセージ、ファイルパスを表示します。コミットハッシュは含みません | `false` | -| `output.git.includeLogsCount` | 含めるGitログのコミット数。開発パターンを理解するための履歴の深さを制限します | `50` | +| `output.git.includeLogsCount` | 含めるGitログのコミット数(最新からの件数)。開発パターンを理解するための履歴の深さを制限します | `50` |
193-195: Augment the bullets with explicit hash exclusion and a short caution.Reinforce privacy and help users anticipate token growth from logs.
- `includeLogs`: trueに設定すると、Gitログを出力に含めます。コミット履歴の日時、メッセージ、ファイルパスが表示され、AIがどのファイルが一緒に変更される傾向があるかを理解できます。デフォルト: `false` + `includeLogs`: trueに設定すると、Gitログを出力に含めます。コミット履歴の日時(ISO 8601)、メッセージ、ファイルパスが表示され、AIがどのファイルが一緒に変更される傾向があるかを理解できます。コミットハッシュは含まれません。デフォルト: `false` - `includeLogsCount`: 含めるGitログのコミット数。開発パターンの分析に使用する履歴の深さを制御します。デフォルト: `50` + `includeLogsCount`: 含めるGitログのコミット数(最新からの件数)。開発パターンの分析に使用する履歴の深さを制御します。デフォルト: `50` + 注意: コミットメッセージは機密情報を含む場合があります。必要に応じて件数を絞る、あるいはセキュリティチェックを有効にしてください。
203-206: Add CLI-equivalent usage right below the config snippet for quick copy/paste.This improves discoverability for users who prefer flags over config files.
You can append after the code block:
# CLI の同等オプション repomix --include-logs --include-logs-count 30
102-104: Mark the code fence as JSON5 and clarify log count scopeThe example at website/client/src/ja/guide/configuration.md (lines 102–104) is currently wrapped in a
json block, but since the guide explicitly supports JSON5 syntax (line 51), please update it tojson5 so that comments and trailing commas render correctly.Optional: add a one-line note that
includeLogsCountapplies to the repository’s latest N commits (not per file), to clarify its scope.website/client/src/pt-br/guide/configuration.md (4)
42-43: Clarify semantics and keep “Git” capitalization consistent; also note hashes omission and ISO datesGood addition. Minor wording tweaks will set clear expectations and improve consistency with the rest of the page that capitalizes “Git”.
- | `output.git.includeLogs` | Indica se deve incluir logs do git na saída. Mostra histórico de commits com datas, mensagens e caminhos de arquivos | `false` | - | `output.git.includeLogsCount` | Número de commits do log do git para incluir na saída | `50` | + | `output.git.includeLogs` | Inclui o histórico de commits do Git na saída (sem hashes), com datas em formato ISO 8601, mensagens e caminhos de arquivos | `false` | + | `output.git.includeLogsCount` | Quantidade de commits recentes a incluir no log do Git | `50` |
102-105: Add a brief JSON5 note about sensitivity and formats in the full config exampleSince this is a “kitchen sink” example and JSON5 comments are supported, a short inline note helps readers understand the implications of including logs.
"git": { "sortByChanges": true, "sortByChangesMaxCommits": 100, - "includeDiffs": false, - "includeLogs": false, - "includeLogsCount": 50 + "includeDiffs": false, + // Logs de commits (sem hashes; datas em ISO 8601). Reveja mensagens antes de compartilhar. + "includeLogs": false, + "includeLogsCount": 50 }
193-195: Enrich the Git logs bullets: omit hashes, mention ISO dates, and add a short cautionAlso fixes minor style issues (“Git” capitalization; slightly smoother PT-BR phrasing). The extra sentence acknowledges potential sensitivity in commit messages.
- - `includeLogs`: Quando verdadeiro, inclui o histórico de commits Git na saída. Mostra datas de commit, mensagens e caminhos de arquivos para cada commit. Isso ajuda a IA a entender padrões de desenvolvimento e relacionamentos entre arquivos. Padrão: `false` - - `includeLogsCount`: O número de commits recentes para incluir nos logs git. Padrão: `50` + - `includeLogs`: Quando verdadeiro, inclui o histórico de commits do Git na saída (sem hashes). Mostra datas em ISO 8601, mensagens e caminhos de arquivos por commit, ajudando a IA a entender padrões de desenvolvimento e relacionamentos entre arquivos. Padrão: `false`. Atenção: mensagens de commit podem conter informações sensíveis — revise antes de compartilhar. + - `includeLogsCount`: Quantidade de commits recentes a incluir no log do Git (do mais recente para o mais antigo). Padrão: `50`
203-206: Adicione o comentário JSON5 paraincludeLogsno exemplo de configuraçãoPara reforçar as observações sem fazer o leitor retornar à tabela acima, insira o seguinte comentário JSON5 após a propriedade
includeLogsno blocogitemwebsite/client/src/pt-br/guide/configuration.md(linhas ~203–206):"includeDiffs": true, "includeLogs": true, + // Inclui logs de commits (sem hashes; datas em ISO 8601). Pode conter conteúdo sensível. "includeLogsCount": 25Verificações já confirmadas:
- Em
src/config/configSchema.ts, as chavesincludeLogs(padrão:false) eincludeLogsCount(padrão:50) estão definidas.- Em
src/cli/cliRun.ts, as flags--include-logs(mensagem: “include git logs in the output (includes commit history with dates, messages, and file paths)”) e--include-logs-count <count>existem conforme documentação.website/client/src/zh-cn/guide/configuration.md (3)
42-43: Clarify log contents and add token-cost hint.Align wording with the implementation details: ISO dates, “提交消息” phrasing, and that commit hashes are excluded. Also hint that larger history increases token usage.
Apply this diff:
-| `output.git.includeLogs` | 是否在输出中包含Git日志。显示提交历史的日期、消息和文件路径 | `false` | -| `output.git.includeLogsCount` | 要包含的Git日志提交数量。限制历史深度以了解开发模式 | `50` | +| `output.git.includeLogs` | 是否在输出中包含Git日志。显示提交历史的日期(ISO格式)、提交消息和文件路径(不包含提交哈希) | `false` | +| `output.git.includeLogsCount` | 要包含的Git日志提交数量。用于分析开发模式的历史深度(较大值会显著增加输出与令牌消耗) | `50` |
203-205: Optional: add an inline JSON5 comment to signal token impact.Small reader aid; JSON5 allows comments.
Apply this diff:
- "includeLogs": true, - "includeLogsCount": 30 + "includeLogs": true, + "includeLogsCount": 30 // 较大值会增加输出体积与令牌消耗
193-194: Update Chinese docs forincludeLogsandincludeLogsCount调整配置文档,补充两点重要行为,并优化标点和表达:
- `includeLogs`:当设置为true时,在输出中包含Git日志。显示提交历史的日期、消息和文件路径,帮助AI理解哪些文件通常一起更改。默认值:`false` - `includeLogsCount`:要包含的Git日志提交数量。控制用于分析开发模式的历史深度。默认值:`50` + `includeLogs`:当设置为true时,在输出中包含Git日志。显示提交历史的日期(ISO格式)、提交消息和文件路径(不包含提交哈希),帮助AI理解哪些文件通常一起更改;日志内容同样会经过安全检查。默认值:`false` + `includeLogsCount`:要包含的Git日志提交数量。控制用于分析开发模式的历史深度;较大值会增加输出体积与令牌消耗。默认值:`50`请在
website/client/src/zh-cn/guide/configuration.md的第193–194行应用以上修改。website/client/src/zh-cn/guide/command-line-options.md (2)
31-32: Clarify content and capitalization; document that commit hashes are excluded.
- Use the proper noun “Git”.
- Explicitly mention ISO date format and that commit hashes are intentionally excluded (privacy/stability), which aligns with the PR summary.
- Note that
--include-logs-countonly applies when logs are enabled.Apply this diff:
- - `--include-logs`: 在输出中包含git日志(包含日期、消息和文件路径的提交历史) - - `--include-logs-count <count>`: 要包含的git日志提交数量(默认:50) + - `--include-logs`: 在输出中包含 Git 日志(提交日期[ISO 8601]、提交消息、变更的文件路径;不包含提交哈希) + - `--include-logs-count <count>`: 要包含的 Git 日志提交数量(默认:50,仅在启用 `--include-logs` 时生效)
75-79: Polish examples and keep terminology consistent.
- Standardize “Git” capitalization and spacing with Chinese text.
- Reinforce that hashes are excluded in the first example comment.
Apply this diff:
-# Git集成功能 -repomix --include-logs # 包含git日志(默认50个提交) -repomix --include-logs --include-logs-count 10 # 包含最近10个提交 -repomix --include-diffs --include-logs # 同时包含差异和日志 +# Git 集成功能 +repomix --include-logs # 包含 Git 日志(默认 50 个提交;不包含提交哈希) +repomix --include-logs --include-logs-count 10 # 包含最近 10 个提交 +repomix --include-diffs --include-logs # 同时包含差异和日志website/client/src/zh-tw/guide/usage.md (2)
96-113: Clear Git integration usage; add a brief note on token cost and privacyGreat addition. To set correct expectations and align with the implementation (hashes omitted), add a short note after the examples about token growth and the omission of commit hashes.
Apply this diff to insert a note block right after the command examples:
repomix --include-diffs --include-logs+> [!NOTE]
+> 啟用--include-logs會增加輸出權杖數;可透過--include-logs-count控制包含的提交數量。
+> 為了隱私與輸出穩定性,提交雜湊(commit hash)會被省略,僅包含日期、訊息與檔案路徑。
+
這會添加有價值的脈絡資訊:--- `114-119`: **Extend the bullets with privacy detail (hashes omitted)** Explicitly stating that commit hashes are omitted helps avoid confusion and matches the core implementation. ```diff - **檔案關係**:了解哪些檔案在同一次提交中被修改 +- **隱私與穩定性**:提交雜湊已省略;僅包含日期、訊息與檔案路徑website/client/src/fr/guide/output.md (1)
33-43: XML sample LGTM; embed a one-line note about omitted hashes inside the sampleIncluding an inline XML comment clarifies the output contract without breaking layout.
<git_logs> +<!-- Les hachages de commit sont intentionnellement omis ; seuls la date, le message et les chemins de fichiers sont inclus. --> 2025-08-20 00:47:19 +0900|feat(cli): Add --include-logs option for git commit history README.md src/cli/cliRun.tstests/mcp/tools/packCodebaseTool.test.ts (2)
64-105: Reflect new git-log config defaults in the mocked config (optional)To keep mocks aligned with runtime defaults and avoid future drift, consider including
includeLogsandincludeLogsCountin the mockedconfig.output.git.git: { sortByChanges: true, sortByChangesMaxCommits: 100, includeDiffs: false, + includeLogs: false, + includeLogsCount: 50, },
116-138: Pass-through of new options via MCP tool (optional coverage)If the MCP tool supports forwarding
--include-logsand--include-logs-count, extend this test to cover those arguments and the expectedrunClicall. This keeps parity between CLI and MCP usage.test('should handle custom options', async () => { const testDir = '/test/project'; const options = { directory: testDir, compress: false, includePatterns: '**/*.js', ignorePatterns: 'test/**', - topFilesLength: 10, + topFilesLength: 10, + // New options under test: + includeLogs: true, + includeLogsCount: 7, }; await toolHandler(options); expect(runCli).toHaveBeenCalledWith( ['.'], testDir, expect.objectContaining({ compress: false, include: '**/*.js', ignore: 'test/**', topFilesLen: 10, + includeLogs: true, + includeLogsCount: 7, }), ); });website/client/src/pt-br/guide/usage.md (2)
96-113: Boa adição; inclua nota sobre tokens e privacidadeSugiro adicionar uma observação curta sobre aumento de tokens e omissão de hashes para alinhar expectativas com a implementação.
repomix --include-diffs --include-logs+> [!NOTE]
+> Ativar--include-logsaumenta a contagem de tokens; use--include-logs-countpara limitar a quantidade de commits incluídos.
+> Por privacidade e estabilidade de saída, os hashes de commit são omitidos; somente data, mensagem e caminhos de arquivos são incluídos.
+
Isso adiciona contexto valioso sobre:--- `114-119`: **Acrescente detalhe de privacidade (hashes omitidos)** Pequeno ajuste para esclarecer o contrato de saída. ```diff - **Relacionamentos entre arquivos**: Entender quais arquivos são modificados nos mesmos commits +- **Privacidade e estabilidade**: hashes de commit são omitidos; apenas data, mensagem e caminhos de arquivos são incluídostests/config/configSchema.test.ts (2)
219-221: Merged schema: cover includeLogs/includeLogsCount with precedence testsParsing is validated here; consider adding a dedicated test ensuring CLI options override file config for these two fields in the merged result (e.g., file sets includeLogs=false/includeLogsCount=50, CLI sets true/10 → merged should be true/10). This catches precedence regressions.
I can draft a CLI merge test if helpful.
121-123: Add includeLogsCount boundary/type tests and clarify default behaviorThe Zod schema enforces
includeLogsCountas an integer ≥ 1 with a default of 50—but no upper bound is defined (seesrc/config/configSchema.ts:108–109). To ensure misconfigurations are caught and the intended constraints are clear, please add tests covering:
- Invalid values (should throw):
includeLogsCount: 0includeLogsCount: -1includeLogsCount: 10.5(non-integer)includeLogsCount: '10'(wrong type)- Valid large value (should parse):
- e.g.
includeLogsCount: 10000(demonstrates absence of an upper bound)- Document the default explicitly in your test (currently shown as
includeLogsCount: 50)Example test additions in
tests/config/configSchema.test.ts:it('rejects non-positive and non-integer includeLogsCount values', () => { const base = { output: { git: { includeLogs: true } } }; for (const bad of [0, -1, 10.5, '10' as any]) { expect(() => repomixConfigDefaultSchema.parse({ ...base, output: { git: { ...base.output.git, includeLogsCount: bad } } })).toThrow(); } }); it('accepts large integer includeLogsCount values', () => { const cfg = repomixConfigDefaultSchema.parse({ output: { git: { includeLogs: true, includeLogsCount: 10000 } }, }); expect(cfg.output.git.includeLogsCount).toBe(10000); });website/client/src/vi/guide/command-line-options.md (2)
31-32: Clarify wording and note that commit hashes are excludedSlight VN phrasing improvement and align docs with implementation (hashes omitted):
- - `--include-logs`: Bao gồm nhật ký git trong đầu ra (bao gồm lịch sử commit với ngày tháng, thông điệp và đường dẫn tệp) - - `--include-logs-count <count>`: Số lượng commit git logs để bao gồm (mặc định: 50) + - `--include-logs`: Bao gồm nhật ký git trong đầu ra (gồm lịch sử commit với ngày, thông điệp và đường dẫn tệp; không bao gồm hash commit) + - `--include-logs-count <count>`: Số lượng commit trong nhật ký git cần bao gồm (mặc định: 50)
92-97: Examples look good; consider adding a combined count exampleOptional addition to demonstrate count with diffs+logs:
repomix --include-diffs --include-logs # Bao gồm cả diff và logs +repomix --include-diffs --include-logs --include-logs-count 10 # Kết hợp diff + 10 commit gần nhấtwebsite/client/src/fr/guide/usage.md (1)
100-116: Mention that commit hashes are excluded (privacy/compactness)Adding a short note improves clarity and sets expectation:
-### Intégration Git +### Intégration Git + +> Remarque : les hachages de commit sont exclus pour limiter la fuite potentielle d’identifiants et réduire le bruit.website/client/src/es/guide/command-line-options.md (1)
31-33: Improve wording and keep “por defecto” consistent; mention hashes are excluded- - `--include-logs`: Incluir logs de git en la salida (incluye historial de commits con fechas, mensajes y rutas de archivos) - - `--include-logs-count <count>`: Número de commits de log de git a incluir (predeterminado: 50) + - `--include-logs`: Incluir logs de git en la salida (historial de commits con fechas, mensajes y rutas de archivos; sin hashes de commit). + - `--include-logs-count <count>`: Número de commits de git a incluir en los logs (por defecto: 50).website/client/src/de/guide/output.md (2)
40-50: Use structured XML in the example to match the template and improve parseabilityThe example currently shows raw file paths as text under
<git_logs>. Since the XML template can emit<file>elements per path, reflecting that here improves clarity and keeps docs aligned.Apply this diff to the XML example block:
-<git_logs> -2025-08-20 00:47:19 +0900|feat(cli): Add --include-logs option for git commit history -README.md -src/cli/cliRun.ts -src/core/git/gitCommand.ts -src/core/git/gitLogHandle.ts -src/core/output/outputGenerate.ts - -2025-08-21 00:09:43 +0900|Merge pull request #795 from yamadashy/chore/ratchet-update-ci -.github/workflows/ratchet-update.yml -</git_logs> +<git_logs> + <git_log_commit> + <date>2025-08-20 00:47:19 +0900</date> + <message>feat(cli): Add --include-logs option for git commit history</message> + <files> + <file>README.md</file> + <file>src/cli/cliRun.ts</file> + <file>src/core/git/gitCommand.ts</file> + <file>src/core/git/gitLogHandle.ts</file> + <file>src/core/output/outputGenerate.ts</file> + </files> + </git_log_commit> + <git_log_commit> + <date>2025-08-21 00:09:43 +0900</date> + <message>Merge pull request #795 from yamadashy/chore/ratchet-update-ci</message> + <files> + <file>.github/workflows/ratchet-update.yml</file> + </files> + </git_log_commit> +</git_logs>Ensure the surrounding code fence for the XML block is correctly closed before the “## Markdown-Format” heading; otherwise, the rest renders as code.
81-92: Name the fenced code block for Git-LogsAdd a language hint (e.g.,
text) to the Git-Logs fenced block for consistent highlighting and tooling.-``` +```text 2025-08-20 00:47:19 +0900|feat(cli): Add --include-logs option for git commit history README.md src/cli/cliRun.ts src/core/git/gitCommand.ts src/core/git/gitLogHandle.ts src/core/output/outputGenerate.ts 2025-08-21 00:09:43 +0900|Merge pull request #795 from yamadashy/chore/ratchet-update-ci .github/workflows/ratchet-update.yml -``` +```website/client/src/zh-tw/guide/output.md (2)
36-55: Structure<files>with<file>entries in the XML sampleMirror the XML template’s structured output to improve readability and downstream parsing.
<git_logs> <git_log_commit> <date>2025-08-20 00:47:19 +0900</date> <message>feat(cli): Add --include-logs option for git commit history</message> - <files> - README.md - src/cli/cliRun.ts - src/core/git/gitCommand.ts - src/core/git/gitLogHandle.ts - src/core/output/outputGenerate.ts - </files> + <files> + <file>README.md</file> + <file>src/cli/cliRun.ts</file> + <file>src/core/git/gitCommand.ts</file> + <file>src/core/git/gitLogHandle.ts</file> + <file>src/core/output/outputGenerate.ts</file> + </files> </git_log_commit> <git_log_commit> <date>2025-08-21 00:09:43 +0900</date> <message>Merge pull request #795 from yamadashy/chore/ratchet-update-ci</message> - <files> - .github/workflows/ratchet-update.yml - </files> + <files> + <file>.github/workflows/ratchet-update.yml</file> + </files> </git_log_commit> </git_logs>
91-102: Add a language to the fenced code block (fixes MD040)The Markdown linter warning is valid. Use
textfor the Git log block.-``` +```text 2025-08-20 00:47:19 +0900|feat(cli): Add --include-logs option for git commit history README.md src/cli/cliRun.ts src/core/git/gitCommand.ts src/core/git/gitLogHandle.ts src/core/output/outputGenerate.ts 2025-08-21 00:09:43 +0900|Merge pull request #795 from yamadashy/chore/ratchet-update-ci .github/workflows/ratchet-update.yml -``` +```website/client/src/zh-cn/guide/usage.md (1)
96-119: 补充隐私/安全说明(不含提交哈希)为避免用户误解,建议在该段末尾增加一句说明:日志中故意不包含提交哈希,仅展示日期、提交信息和变更的文件路径。
可在此段落末尾追加:
- **文件关系**:理解在同一提交中修改的文件 + +> [!NOTE] +> 出于隐私与简洁考虑,Git 日志不会包含提交哈希,仅展示日期、提交信息和变更的文件路径。website/client/src/es/guide/configuration.md (2)
42-43: Aclare que los hashes de commit no se incluyen en los logsLa descripción es correcta, pero sugiero añadir una nota breve para que los usuarios sepan que por privacidad no se muestran hashes.
-| `output.git.includeLogs` | Indica si se deben incluir los logs de git en la salida. Muestra el historial de commits con fechas, mensajes y rutas de archivos | `false` | +| `output.git.includeLogs` | Indica si se deben incluir los logs de git en la salida. Muestra el historial de commits con fechas, mensajes y rutas de archivos (sin hashes de commit) | `false` |
193-195: Añada una nota sobre la omisión de hashes de commitRefuerza la expectativa del usuario y alinea la guía con las prácticas de privacidad del proyecto.
-- `includeLogs`: Cuando es verdadero, incluye el historial de commits Git en la salida. Muestra fechas de commits, mensajes y rutas de archivos para cada commit. Esto ayuda a la IA a entender patrones de desarrollo y relaciones entre archivos. Predeterminado: `false` +- `includeLogs`: Cuando es verdadero, incluye el historial de commits Git en la salida. Muestra fechas de commits, mensajes y rutas de archivos para cada commit (sin hashes de commit). Esto ayuda a la IA a entender patrones de desarrollo y relaciones entre archivos. Predeterminado: `false`website/client/src/en/guide/usage.md (1)
96-119: Add a short privacy note (commit hashes omitted)Preempt questions by clarifying that hashes aren’t included in logs by design.
- **File relationships**: Understanding which files are modified in the same commits + +> [!NOTE] +> For privacy and brevity, commit hashes are intentionally omitted; only dates, messages, and changed file paths are shown.website/client/src/pt-br/guide/output.md (4)
6-6: Remover espaço em branco à direitaHá um espaço extra após “Texto simples”. Pequeno ajuste de formatação.
-- Texto simples +- Texto simples
36-56: Considere substituir commits reais por placeholdersEm exemplos de documentação, entradas reais (datas, mensagens e caminhos de arquivos) envelhecem e exigem manutenção. Recomendo usar placeholders genéricos.
Exemplo:
-<date>2025-08-20 00:47:19 +0900</date> -<message>feat(cli): Add --include-logs option for git commit history</message> +<date>YYYY-MM-DD HH:mm:ss Z</date> +<message>feat(cli): Descrição do commit</message> @@ -<date>2025-08-21 00:09:43 +0900</date> -<message>Merge pull request #795 from yamadashy/chore/ratchet-update-ci</message> +<date>YYYY-MM-DD HH:mm:ss Z</date> +<message>chore(ci): Atualizações no pipeline</message>
59-62: Verifique espaçamento em volta do bloco “::: tip”Para evitar problemas de renderização no Markdown engine (VitePress), mantenha uma linha em branco antes e depois do bloco de admonição.
-``` -::: tip Por que XML? +``` + +::: tip Por que XML? @@ -::: +::: + -## Formato Markdown +## Formato Markdown
92-104: Especifique a linguagem do fence para os logs do GitAdicionar
textmelhora linting e previsibilidade de renderização.-``` +```text 2025-08-20 00:47:19 +0900|feat(cli): Add --include-logs option for git commit history README.md @@ -.github/workflows/ratchet-update.yml -``` +.github/workflows/ratchet-update.yml +```website/client/src/de/guide/configuration.md (2)
42-43: Klarstellen: Commit-Hashes werden nicht ausgegebenErgänzen Sie einen kurzen Hinweis zur Privatsphäre.
-| `output.git.includeLogs` | Ob Git-Logs in der Ausgabe enthalten sein sollen. Zeigt Commit-Historie mit Daten, Nachrichten und Dateipfaden an | `false` | +| `output.git.includeLogs` | Ob Git-Logs in der Ausgabe enthalten sein sollen. Zeigt Commit-Historie mit Daten, Nachrichten und Dateipfaden an (ohne Commit-Hashes) | `false` |
193-195: Privatheitshinweis in der Beschreibung ergänzenExplizit erwähnen, dass keine Commit-Hashes ausgegeben werden.
-- `includeLogs`: Wenn auf true gesetzt, werden Git-Logs in die Ausgabe einbezogen. Zeigt Commit-Historie mit Daten, Nachrichten und Dateipfaden für jeden Commit an. Dies hilft der KI, Entwicklungsmuster und Dateibeziehungen zu verstehen. Standard: `false` +- `includeLogs`: Wenn auf true gesetzt, werden Git-Logs in die Ausgabe einbezogen. Zeigt Commit-Historie mit Daten, Nachrichten und Dateipfaden (ohne Commit-Hashes) für jeden Commit an. Dies hilft der KI, Entwicklungsmuster und Dateibeziehungen zu verstehen. Standard: `false`website/client/src/id/guide/usage.md (3)
111-127: Nice addition: clear, minimal Git integration examples.The options and examples read well. Consider adding a short note about prerequisites (Git installed and running inside a Git repository) and clarifying remote-behavior if
--remoteis used.Would you like me to scan the codebase and docs to confirm whether
--include-logsis supported when using--remote, and update this section accordingly?
129-134: Add privacy/token caveats and note that commit hashes are excluded.This is a good place to call out privacy and token-size implications, and to document that commit hashes are intentionally excluded.
Apply this diff to append a concise bullet:
- **Hubungan file**: Memahami file mana yang dimodifikasi dalam commit yang sama + - **Privasi & ukuran**: Hash commit tidak disertakan; konten log dipindai oleh pemeriksaan keamanan. Gunakan `--include-logs-count` untuk membatasi token.
186-207: Keep “Additional Options” concise and non-duplicative.This section is fine as-is. If these options are already documented elsewhere in Indonesian guides, consider linking instead of duplicating to reduce drift.
If you want, I can scan the Indonesian docs and open a follow-up PR to deduplicate or add cross-links.
website/client/src/id/guide/output.md (2)
79-84: Fix fenced code block language for directory structure (markdownlint MD040).Specify a language for the fenced block to satisfy markdownlint and improve rendering.
Apply this diff:
-``` +```text src/ index.ts utils/ helper.ts--- `92-104`: **Localize heading and add language to “Git Logs” fenced block (markdownlint MD040).** - Use Indonesian for the heading (“Log Git”). - Provide a language (text) for the fenced block. Apply this diff: ```diff -# Git Logs -``` +# Log Git +```text 2025-08-20 00:47:19 +0900|feat(cli): Add --include-logs option for git commit history README.md src/cli/cliRun.ts src/core/git/gitCommand.ts src/core/git/gitLogHandle.ts src/core/output/outputGenerate.ts 2025-08-21 00:09:43 +0900|Merge pull request #795 from yamadashy/chore/ratchet-update-ci .github/workflows/ratchet-update.yml</blockquote></details> <details> <summary>website/client/src/hi/guide/output.md (2)</summary><blockquote> `79-84`: **Add language to fenced directory-structure block (markdownlint MD040).** Provide a language for the code fence. Apply this diff: ```diff -``` +```text src/ index.ts utils/ helper.ts--- `92-104`: **Localize heading and add language to “Git Logs” fenced block.** - Prefer “Git लॉग” for the heading. - Add `text` to the code fence to resolve MD040. Apply this diff: ```diff -# Git Logs -``` +# Git लॉग +```text 2025-08-20 00:47:19 +0900|feat(cli): Add --include-logs option for git commit history README.md src/cli/cliRun.ts src/core/git/gitCommand.ts src/core/git/gitLogHandle.ts src/core/output/outputGenerate.ts 2025-08-21 00:09:43 +0900|Merge pull request #795 from yamadashy/chore/ratchet-update-ci .github/workflows/ratchet-update.yml</blockquote></details> <details> <summary>website/client/src/en/guide/command-line-options.md (2)</summary><blockquote> `31-33`: **Explicitly mention that commit hashes are excluded.** This aligns the CLI docs with the implementation/PR summary and helps set privacy expectations. Apply this diff: ```diff -- `--include-logs`: Include git logs in the output (includes commit history with dates, messages, and file paths) +- `--include-logs`: Include git logs in the output (includes commit history with dates, messages, and file paths; excludes commit hashes) - `--include-logs-count <count>`: Number of git log commits to include (default: 50)
90-95: Tiny example tweak: add a caution about token size and privacy.A short comment improves UX for first-time users enabling logs.
Apply this diff:
# Git integration -repomix --include-diffs # Include git diffs for uncommitted changes -repomix --include-logs # Include git logs (last 50 commits by default) +repomix --include-diffs # Include git diffs for uncommitted changes +repomix --include-logs # Include git logs (last 50 commits by default; hashes excluded; may increase token count) repomix --include-logs --include-logs-count 10 # Include last 10 commits repomix --include-diffs --include-logs # Include both diffs and logstests/core/metrics/diffTokenCount.test.ts (3)
103-109: Also assert git log metric default to strengthen coverage.You’re already wiring
calculateGitLogMetrics. Add an assertion forgitLogTokenCount= 0 so regressions in the metrics aggregator are caught here too.Apply this diff:
const result = await calculateMetrics( processedFiles, output, vi.fn(), // Progress callback config, { workTreeDiffContent: sampleDiff, stagedDiffContent: '', }, undefined, { calculateSelectiveFileMetrics: vi.fn().mockResolvedValue([]), calculateOutputMetrics: mockCalculateOutputMetrics, calculateGitDiffMetrics: vi.fn().mockResolvedValue(25), calculateGitLogMetrics: vi.fn().mockResolvedValue({ gitLogTokenCount: 0 }), }, ); // Check token counting was called with the diff content expect(result).toHaveProperty('gitDiffTokenCount'); // Mock returns 25 tokens for git diff content expect(result.gitDiffTokenCount).toBe(25); + // And git logs are not counted when no logs provided + expect(result).toHaveProperty('gitLogTokenCount', 0);
178-184: Mirror the “no-logs” assertion in the diffs-disabled path.This keeps behavior consistent and explicit when diffs/logs are off.
Apply this diff:
const result = await calculateMetrics( processedFiles, output, vi.fn(), // Progress callback config, undefined, // No diff content undefined, { calculateSelectiveFileMetrics: vi.fn().mockResolvedValue([]), calculateOutputMetrics: mockCalculateOutputMetrics, calculateGitDiffMetrics: vi.fn().mockResolvedValue(0), calculateGitLogMetrics: vi.fn().mockResolvedValue({ gitLogTokenCount: 0 }), }, ); // Git diff should return 0 when disabled expect(result.gitDiffTokenCount).toBe(0); + // Git logs should also be 0 by default here + expect(result.gitLogTokenCount).toBe(0);
251-257: Add the same assertion for the “undefined diffContent” scenario.Ensures aggregator remains robust when diffs are enabled but diff/log content is absent.
Apply this diff:
const result = await calculateMetrics( processedFiles, output, vi.fn(), // Progress callback config, undefined, // No diff content undefined, { calculateSelectiveFileMetrics: vi.fn().mockResolvedValue([]), calculateOutputMetrics: mockCalculateOutputMetrics, calculateGitDiffMetrics: vi.fn().mockResolvedValue(0), calculateGitLogMetrics: vi.fn().mockResolvedValue({ gitLogTokenCount: 0 }), }, ); // Git diff should return 0 when content is undefined expect(result.gitDiffTokenCount).toBe(0); + // Git logs should also be 0 in this scenario + expect(result.gitLogTokenCount).toBe(0);tests/core/packager.test.ts (1)
82-88: LGTM: updated call signatures correctly thread git-log params as trailing optionals
- validateFileSafety, generateOutput, and calculateMetrics are asserted with the extra undefined placeholders in the right positions. This matches the new public signatures and keeps the orchestration test focused.
Consider adding one complementary test where includeLogs is enabled (and deps.mock getGitLogs returns a small logContent) to assert these calls receive a non-undefined gitLogResult and that pack propagates gitLogTokenCount in the final result. This will catch wiring regressions early without increasing test fragility.
Also applies to: 96-97, 106-107
src/core/security/securityCheck.ts (1)
58-60: Minor: derive pool size from tasks.length to remove duplicationYou pre-compute the pool size from the three task buckets and then re-compute tasks. To avoid drift if future task sources are added/removed, initialize the runner after assembling tasks and use tasks.length.
- const taskRunner = deps.initTaskRunner<SecurityCheckTask, SuspiciousFileResult | null>( - rawFiles.length + gitDiffTasks.length + gitLogTasks.length, - new URL('./workers/securityCheckWorker.js', import.meta.url).href, - ); - const fileTasks = rawFiles.map( + const fileTasks = rawFiles.map( (file) => ({ filePath: file.path, content: file.content, type: 'file', }) satisfies SecurityCheckTask, ); - // Combine file tasks, Git diff tasks, and Git log tasks - const tasks = [...fileTasks, ...gitDiffTasks, ...gitLogTasks]; + // Combine file tasks, Git diff tasks, and Git log tasks + const tasks = [...fileTasks, ...gitDiffTasks, ...gitLogTasks]; + const taskRunner = deps.initTaskRunner<SecurityCheckTask, SuspiciousFileResult | null>( + tasks.length, + new URL('./workers/securityCheckWorker.js', import.meta.url).href, + );Also applies to: 71-72
tests/cli/cliReport.test.ts (1)
88-88: LGTM: reportSecurityCheck call sites updated for the new git-log argumentPassing an empty array for the new suspiciousGitLogResults parameter preserves previous behavior when no logs are included.
Add a focused test that passes a non-empty suspiciousGitLogResults and asserts the CLI prints a separate "Git Logs" section (or similar) so regressions in the reporting path are caught.
Also applies to: 97-97, 117-117
src/core/metrics/calculateMetrics.ts (1)
52-52: Readability: avoid shadowing by destructuring git-log metricsCurrently gitLogTokenCount is a result object, then re-accessed via gitLogTokenCount.gitLogTokenCount. Destructure in Promise.all to improve clarity.
- const [selectiveFileMetrics, totalTokens, gitDiffTokenCount, gitLogTokenCount] = await Promise.all([ + const [selectiveFileMetrics, totalTokens, gitDiffTokenCount, { gitLogTokenCount }] = await Promise.all([ deps.calculateSelectiveFileMetrics( processedFiles, metricsTargetPaths, config.tokenCount.encoding, progressCallback, ), deps.calculateOutputMetrics(output, config.tokenCount.encoding, config.output.filePath), deps.calculateGitDiffMetrics(config, gitDiffResult), deps.calculateGitLogMetrics(config, gitLogResult), ]); ... - gitDiffTokenCount: gitDiffTokenCount, - gitLogTokenCount: gitLogTokenCount.gitLogTokenCount, + gitDiffTokenCount, + gitLogTokenCount,Also applies to: 61-61, 86-87
src/core/metrics/calculateGitLogMetrics.ts (1)
36-51: Nit: unify return-value naming to reduce ceremonyVery minor: you can inline the return with a named destructure for consistency with calculateMetrics.
- const result = await taskRunner.run({ + const result = await taskRunner.run({ content: gitLogResult.logContent, encoding: config.tokenCount.encoding, }); ... - return { - gitLogTokenCount: result, - }; + return { gitLogTokenCount: result };src/cli/cliReport.ts (1)
80-86: Avoid future signature churn: prefer an options object for reportSecurityCheckAdding a new positional parameter works, but it increases fragility with future additions. Switching to a single options object improves readability and backward compatibility.
Apply this diff to change the signature to a destructured options object (body references remain unchanged):
-export const reportSecurityCheck = ( - rootDir: string, - suspiciousFilesResults: SuspiciousFileResult[], - suspiciousGitDiffResults: SuspiciousFileResult[], - suspiciousGitLogResults: SuspiciousFileResult[], - config: RepomixConfigMerged, -) => { +export const reportSecurityCheck = ({ + rootDir, + suspiciousFilesResults, + suspiciousGitDiffResults, + suspiciousGitLogResults, + config, +}: { + rootDir: string; + suspiciousFilesResults: SuspiciousFileResult[]; + suspiciousGitDiffResults: SuspiciousFileResult[]; + suspiciousGitLogResults: SuspiciousFileResult[]; + config: RepomixConfigMerged; +}) => {And update the call site accordingly (see lines 30–36):
- reportSecurityCheck( - cwd, - packResult.suspiciousFilesResults, - packResult.suspiciousGitDiffResults, - packResult.suspiciousGitLogResults, - config, - ); + reportSecurityCheck({ + rootDir: cwd, + suspiciousFilesResults: packResult.suspiciousFilesResults, + suspiciousGitDiffResults: packResult.suspiciousGitDiffResults, + suspiciousGitLogResults: packResult.suspiciousGitLogResults, + config, + });src/core/git/gitLogHandle.ts (4)
24-29: Make parsing robust to CRLF and variable blank-line separatorsSplitting strictly on '\n\n' can break on Windows CRLF or multiple blank lines. Use a regex to split on two or more blank lines across platforms. Likewise, split lines using a cross-platform regex.
- const logEntries = rawLogOutput.split('\n\n'); + // Split on two or more consecutive newlines (supports \n and \r\n and whitespace-only lines) + const logEntries = rawLogOutput.split(/\r?\n\s*\r?\n/); - for (const entry of logEntries) { - const lines = entry.split('\n').filter((line) => line.trim() !== ''); + for (const entry of logEntries) { + const lines = entry.split(/\r?\n/).filter((line) => line.trim() !== '');
87-89: Respect explicit 0 for includeLogsCount using nullish coalescingUsing || forces 0 → 50. If 0 is a valid “include none” value (or you just want correctness), switch to ??.
- const maxCommits = config.output.git?.includeLogsCount || 50; + const maxCommits = config.output.git?.includeLogsCount ?? 50;
18-49: Add parsing unit tests for delimiter and platform edge casesPlease add tests covering:
- CRLF line endings
- Commit subject containing a '|' character
- Commits with zero files
- Multiple blank lines between commits
- Non-ASCII filenames and spaces
I can draft table-driven tests for parseGitLog with representative fixtures if helpful.
31-37: Consider using unambiguous delimiters for git‐log parsingWe’ve confirmed that
execGitLoginsrc/core/git/gitCommand.tscurrently invokes:git log --pretty=format:%ad|%s --date=iso --name-only -n <max>Using
|as the sole separator is brittle since commit messages can themselves contain|. To avoid parsing errors in edge cases, I recommend switching to nonprintable ASCII separators and NUL-delimited filenames:• In src/core/git/gitCommand.ts, change the
--prettyformat and add-z:- '--pretty=format:%ad|%s', + '--pretty=format:%ad%x1f%s%x1e', // %x1f = unit sep, %x1e = record sep + '-z',• In src/core/git/gitLogHandle.ts, replace the
firstLine.indexOf('|')logic with splitting on the record separator (\x1e) and then the unit separator (\x1f):// before: brittle split on '|' - const firstLine = lines[0]; - const separatorIndex = firstLine.indexOf('|'); - if (separatorIndex === -1) continue; - - const date = firstLine.substring(0, separatorIndex); - const message = firstLine.substring(separatorIndex + 1); + // after: unambiguous split on ASCII RS/US + const [rawEntry] = output.split('\x1e'); // split commits + const [date, message] = rawEntry.split('\x1f'); + if (!date || !message) continue;Locations to update:
src/core/git/gitCommand.tsaround theexecGitLogflag arraysrc/core/git/gitLogHandle.tsat the parsing logic (lines 31–37)This change will ensure accurate parsing even when commit subjects or filenames include unusual characters.
- Fix error handling in getGitLogs to properly handle non-Error exceptions - All thrown errors are now properly wrapped as RepomixError with cause - Addresses PR review feedback about potential swallowed exceptions Resolves issue where non-Error exceptions could be silently ignored, ensuring all errors are properly propagated with meaningful context.
- Change git log format from '%ad|%s' to '%x00%ad|%s' (null character prefix) - Update parsing logic to split by null character instead of double newlines - Prevents parsing issues when commit messages contain newlines - Ensures correct record separation regardless of commit message formatting Addresses PR review feedback for more robust git log handling.
…rsing - Explain why null character (\x00) is used as record separator - Document that this approach is more robust than newline-based splitting - Clarify that commit messages may contain newlines, making null character safer - Improve code readability and maintainability for future developers
Combine --include-logs and --include-logs-count option handling into a single block to reduce code duplication and improve maintainability. This addresses the PR feedback about redundant configuration building patterns. - Merge two separate if blocks into one consolidated block - Use conditional spread syntax for cleaner object construction - Add explanatory comment for the git logs configuration section - Maintain same functionality while reducing code repetition
Address Node.js execFileAsync limitation where null bytes in command arguments cause execution to fail. Implement proper separation between Git format strings and JavaScript parsing logic. Changes: - Separate Git format separator (%x00) from JavaScript parsing separator (\x00) - Add GIT_LOG_FORMAT_SEPARATOR constant for Git command formatting - Maintain GIT_LOG_RECORD_SEPARATOR for JavaScript string parsing - Add comprehensive test coverage for git log functionality - Support cross-platform line endings (CRLF/LF) in git log parsing - Add gitLogHandle.test.ts with 13 test cases covering various scenarios This resolves the "string without null bytes" error while maintaining flexibility for custom separators and ensuring robust git log processing across different platforms and git configurations.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces a valuable feature to include git commit history in the output, which can significantly improve the context for AI analysis. The implementation is thorough, covering CLI options, configuration, core logic, security checks, metrics, and output templates. The documentation has also been updated comprehensively across all supported languages. My review focuses on a few areas for improvement, mainly around code duplication to enhance maintainability and a small bug fix in the XML output generation.
Extract logSuspiciousContentWarning helper function to eliminate code duplication between Git diffs and Git logs security warning logic in validateFileSafety.ts. This addresses PR feedback about duplicate code patterns and improves maintainability by following DRY principles.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces a valuable new feature to include git commit history in the output, which will significantly enhance the context available for AI analysis. The implementation is thorough, covering CLI options, configuration, core logic, security checks, metrics, and documentation updates across multiple languages. The code is well-structured, particularly the new gitLogHandle.ts which uses robust parsing for git logs, and the refactoring in cliReport.ts is a nice improvement.
I've identified a couple of minor issues with the XML output generation for this new feature that could lead to inconsistent or malformed XML. I've provided specific suggestions to address these. Overall, this is an excellent and well-executed feature addition.
This PR adds a new
--include-logsfeature that allows users to include git commit history in the output to help AI understand development patterns and file change relationships.Summary
The new feature provides git log information showing:
This helps AI systems understand which files are typically modified together and the development patterns of the codebase.
Key Changes
CLI Options
--include-logsflag to enable git log inclusion--include-logs-count <count>flag to specify number of commits (default: 50)Configuration Support
includeLogsandincludeLogsCountoptions in config schemaCore Implementation
src/core/git/gitLogHandle.tsfor git log processingsrc/core/git/gitCommand.tswithexecGitLogfunctionOutput Templates
Testing & Quality
Example Usage
Example Output
The git logs section appears in the output like this:
Benefits
Checklist
npm run test(All 721 tests passing)npm run lint(No linting errors)