What's wrong
GitPatchBuilder pins host settings that would otherwise change the shape of the patch: prefixes, color, ext-diff, textconv and suppressBlankEmpty. That follows the repo's stated policy. Two settings are not pinned (GitIntegration/Builders/GitPatchBuilder.cs:~180-188).
Context lines
-U is only passed when WithContext(n) is called. WithContext(0) is deliberately refused, because a zero-context hunk needs --unidiff-zero to apply. The default path, where WithContext is never called, instead inherits diff.context from git config.
In a repository with diff.context=0, changing line 25 of a 50-line file produces @@ -25 +25 @@. Feeding that patch to Apply(...).ToIndex() fails with error: patch failed: f.txt:25. This is the failure the WithContext remarks say the builder prevents, and it is reported against the index rather than the config setting.
Rename and copy detection
--find-renames is only added when DetectRenames() is called. Nothing turns renames off otherwise, and git enables them by default:
- Staged renames come back as
Renamed even without DetectRenames().
- With
diff.renames=copies, git emits copy from / copy to headers. The parser ignores those, so a new copied file is reported as Kind = Modified with OriginalPath = null.
Suggested fix
- Always emit
-U{_contextLines ?? 3}.
- Emit
--no-renames unless DetectRenames() was called.
- Optionally, recognise
copy from / copy to in GitPatchParser.ApplyHeaderLine.
- Add a builder test asserting the argument list contains
-U3 and --no-renames by default. Add an integration test with diff.context=0 set in the fixture repository, asserting the patch round-trips through Apply(...).ToIndex().
What's wrong
GitPatchBuilderpins host settings that would otherwise change the shape of the patch: prefixes, color, ext-diff, textconv andsuppressBlankEmpty. That follows the repo's stated policy. Two settings are not pinned (GitIntegration/Builders/GitPatchBuilder.cs:~180-188).Context lines
-Uis only passed whenWithContext(n)is called.WithContext(0)is deliberately refused, because a zero-context hunk needs--unidiff-zeroto apply. The default path, whereWithContextis never called, instead inheritsdiff.contextfrom git config.In a repository with
diff.context=0, changing line 25 of a 50-line file produces@@ -25 +25 @@. Feeding that patch toApply(...).ToIndex()fails witherror: patch failed: f.txt:25. This is the failure theWithContextremarks say the builder prevents, and it is reported against the index rather than the config setting.Rename and copy detection
--find-renamesis only added whenDetectRenames()is called. Nothing turns renames off otherwise, and git enables them by default:Renamedeven withoutDetectRenames().diff.renames=copies, git emitscopy from/copy toheaders. The parser ignores those, so a new copied file is reported asKind = ModifiedwithOriginalPath = null.Suggested fix
-U{_contextLines ?? 3}.--no-renamesunlessDetectRenames()was called.copy from/copy toinGitPatchParser.ApplyHeaderLine.-U3and--no-renamesby default. Add an integration test withdiff.context=0set in the fixture repository, asserting the patch round-trips throughApply(...).ToIndex().