* Generates a string matching the format of a GNU unified diff header excluding * the (optional) timestamp fields with the appropriate from/to file names based * on the file state of the given WorkingDirectoryFileChange
(file: WorkingDirectoryFileChange)
| 41 | * on the file state of the given WorkingDirectoryFileChange |
| 42 | */ |
| 43 | function formatPatchHeaderForFile(file: WorkingDirectoryFileChange) { |
| 44 | switch (file.status.kind) { |
| 45 | case AppFileStatusKind.New: |
| 46 | case AppFileStatusKind.Untracked: |
| 47 | return formatPatchHeader(null, file.path) |
| 48 | |
| 49 | // One might initially believe that renamed files should diff |
| 50 | // against their old path. This is, after all, how git diff |
| 51 | // does it right after a rename. But if we're creating a patch |
| 52 | // to be applied along with a rename we must target the renamed |
| 53 | // file. |
| 54 | case AppFileStatusKind.Renamed: |
| 55 | case AppFileStatusKind.Deleted: |
| 56 | case AppFileStatusKind.Modified: |
| 57 | case AppFileStatusKind.Copied: |
| 58 | // We should not have the ability to format a file that's marked as |
| 59 | // conflicted without more information about it's current state. |
| 60 | // I'd like to get to a point where `WorkingDirectoryFileChange` can be |
| 61 | // differentiated between ordinary, renamed/copied and unmerged entries |
| 62 | // and we can then verify the conflicted file is in a known good state but |
| 63 | // that work needs to be done waaaaaaaay before we get to this point. |
| 64 | case AppFileStatusKind.Conflicted: |
| 65 | return formatPatchHeader(file.path, file.path) |
| 66 | default: |
| 67 | return assertNever(file.status, `Unknown file status ${file.status}`) |
| 68 | } |
| 69 | } |
| 70 | |
| 71 | /** |
| 72 | * Generates a string matching the format of a GNU unified diff hunk header. |
no test coverage detected