Elijah Newren <newren@xxxxxxxxx> writes: > The raw diff format for merges with -c or --cc will only list one > filename, even if rename detection is active and a rename was detected > for the given path. Examples: > > ::100644 100644 100644 fabadb8 cc95eb0 4866510 MM describe.c > ::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM bar.sh > ::100644 100644 100644 e07d6c5 9042e82 ee91881 RR phooey.c > > This doesn't let us know what the original name of bar.sh was in the > first parent, and doesn't let us know what either of the original > names of phooey.c were in either of the parents. In contrast, for > non-merge commits, raw format does provide original filenames (and a > rename score to boot). In order to also provide original filenames > for merge commits, add a --combined-with-paths option (which is only > useful in conjunction with -c, --raw, and -M and thus implies all > those options) so that we can print tab-separated filenames when > renames are involved. This transforms the above output to: > > ::100644 100644 100644 fabadb8 cc95eb0 4866510 MM describe.c > ::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM foo.sh bar.sh > ::100644 100644 100644 e07d6c5 9042e82 ee91881 RR fooey.c fuey.c phooey.c I admit that I designed the original without too much thought. Perhaps we should have avoided discarding info, but it is way too late to fix with a default behaviour change. I am not sure if it is easy for consumers to guess which name on the output line corresponds to which input tree from the status letter, though. Would it make it easier for consumers if this showed names in all input trees if any of them is different from the name in the resulting tree, I wonder? Even in that case, the consumer must know some rule like "if R or C appears in the status column, then we have N preimage names plus the name in the result for N-way merge", so it may not be too bad to force them to know "for each of R or C in the status column, the name in the preimage tree is emitted, and the last name is the name in the result". I dunno. > +For `-c` and `--cc`, only the destination or final path is shown even > +if the file was renamed on any side of history. With > +`--combined-with-paths`, the number of paths printed will be one more > +than the number of 'R' characters in the concatenated status. For > +each 'R' in the concatenated status characters, the original pathname > +on that side of history will be shown, and the final path shown on the > +line will be the path used in the merge. Is it safe for readers to pay attention to only 'R'? Will it stay forever that way? My immediate worry is 'C', but there might be other cases that original and result have different names. > +--combined-with-paths:: > + This flag is similar to -c, but modifies the raw output format for > + merges to also show the original paths when renames are found. > + Implies -c, -M, and --raw. So, --cc -p is not allowed to use this? I was wondering if we want to have a separate "even though traditionally we did not show preimage names in combined output, this option tells Git to do so, regardless of output format used, as long as 'combine-diff' is in effect".
