|
| 1 | +git-merge-file(1) |
| 2 | +============ |
| 3 | + |
| 4 | +NAME |
| 5 | +---- |
| 6 | +git-merge-file - threeway file merge |
| 7 | + |
| 8 | + |
| 9 | +SYNOPSIS |
| 10 | +-------- |
| 11 | +[verse] |
| 12 | +'git-merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]] |
| 13 | + [-p|--stdout] [-q|--quiet] <current-file> <base-file> <other-file> |
| 14 | + |
| 15 | + |
| 16 | +DESCRIPTION |
| 17 | +----------- |
| 18 | +git-file-merge incorporates all changes that lead from the `<base-file>` |
| 19 | +to `<other-file>` into `<current-file>`. The result ordinarily goes into |
| 20 | +`<current-file>`. git-merge-file is useful for combining separate changes |
| 21 | +to an original. Suppose `<base-file>` is the original, and both |
| 22 | +`<current-file>` and `<other-file>` are modifications of `<base-file>`. |
| 23 | +Then git-merge-file combines both changes. |
| 24 | + |
| 25 | +A conflict occurs if both `<current-file>` and `<other-file>` have changes |
| 26 | +in a common segment of lines. If a conflict is found, git-merge-file |
| 27 | +normally outputs a warning and brackets the conflict with <<<<<<< and |
| 28 | +>>>>>>> lines. A typical conflict will look like this: |
| 29 | + |
| 30 | + <<<<<<< A |
| 31 | + lines in file A |
| 32 | + ======= |
| 33 | + lines in file B |
| 34 | + >>>>>>> B |
| 35 | + |
| 36 | +If there are conflicts, the user should edit the result and delete one of |
| 37 | +the alternatives. |
| 38 | + |
| 39 | +The exit value of this program is negative on error, and the number of |
| 40 | +conflicts otherwise. If the merge was clean, the exit value is 0. |
| 41 | + |
| 42 | +git-merge-file is designed to be a minimal clone of RCS merge, that is, it |
| 43 | +implements all of RCS merge's functionality which is needed by |
| 44 | +gitlink:git[1]. |
| 45 | + |
| 46 | + |
| 47 | +OPTIONS |
| 48 | +------- |
| 49 | + |
| 50 | +-L <label>:: |
| 51 | + This option may be given up to three times, and |
| 52 | + specifies labels to be used in place of the |
| 53 | + corresponding file names in conflict reports. That is, |
| 54 | + `git-merge-file -L x -L y -L z a b c` generates output that |
| 55 | + looks like it came from files x, y and z instead of |
| 56 | + from files a, b and c. |
| 57 | + |
| 58 | +-p:: |
| 59 | + Send results to standard output instead of overwriting |
| 60 | + `<current-file>`. |
| 61 | + |
| 62 | +-q:: |
| 63 | + Quiet; do not warn about conflicts. |
| 64 | + |
| 65 | + |
| 66 | +EXAMPLES |
| 67 | +-------- |
| 68 | + |
| 69 | +git merge-file README.my README README.upstream:: |
| 70 | + |
| 71 | + combines the changes of README.my and README.upstream since README, |
| 72 | + tries to merge them and writes the result into README.my. |
| 73 | + |
| 74 | +git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345:: |
| 75 | + |
| 76 | + merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels |
| 77 | + `a` and `c` instead of `tmp/a123` and `tmp/c345`. |
| 78 | + |
| 79 | + |
| 80 | +Author |
| 81 | +------ |
| 82 | +Written by Johannes Schindelin <johannes.schindelin@gmx.de> |
| 83 | + |
| 84 | + |
| 85 | +Documentation |
| 86 | +-------------- |
| 87 | +Documentation by Johannes Schindelin and the git-list <git@vger.kernel.org>, |
| 88 | +with parts copied from the original documentation of RCS merge. |
| 89 | + |
| 90 | +GIT |
| 91 | +--- |
| 92 | +Part of the gitlink:git[7] suite |
0 commit comments