Hi, On Thu, Jan 24, 2019 at 6:19 PM brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Jan 24, 2019 at 08:46:54AM -0800, Elijah Newren wrote: > > The critical part of the patch is the few line change to > > show_raw_diff(), the rest is plumbing to set that up. > > > > This patch was based out of Peff's suggestion[1] to fix diff-tree to > > do what I needed rather than bending fast-export to cover my usecase; > > I've been running with a hacky version of this patch for a while and > > finally cleaned it up. > > > > [1] https://public-inbox.org/git/20181114071454.GB19904@xxxxxxxxxxxxxxxxxxxxx/ > > > > As an alternative, I considered perhaps trying to sell it as a bugfix > > (how often do people use -M, -c, and --raw together and have renames > > in merge commits -- can I just change the format to include the old > > names), but was worried that since diff-tree is plumbing and that the > > format was documented to not include original filename(s), that I'd be > > breaking backward compatibility in an important way for someone and > > thus opted for a new flag to get the behavior I needed. > > > > I did struggle a bit to come up with a name for the option; if others > > have better suggestions, I'm happy to switch. > > Maybe --all-names? You should definitely let other people chime in on > this as well; it should be obvious by now that I'm no expert on naming > things. --all-names may work. Two possible worries: 1) Would people expect the output when using this option to be of the form: ::100644 100644 100644 fabadb8 cc95eb0 4866510 MM describe.c describe.c describe.c In other words, even if there are no renames involved, would they expect us to show the filename from each side of the merge? I was trying to make the combined diff output format more similar to how we handle non-merge commits; we only show more than one filename when a rename is involved. 2) When looking through manpages I have often found an option that I thought was related to what I wanted, only to discover that a short semi-ambiguous option had a much different context in mind than I did and thus performed some operation entirely unrelated to anything I was interested in. I suspect that this won't be a highly used option, as such, a longer name to disambiguate seemed reasonable. Of course --combined-with-paths isn't fully descriptive either, and making it even longer might be annoying, so... *shrug* > > > Range-diff: > > 1: 29e9ddf532 = 1: 29e9ddf532 log,diff-tree: add --combined-with-paths options for merges with renames > > > > Documentation/diff-format.txt | 23 +++++++++++++--- > > Documentation/git-diff-tree.txt | 9 +++++-- > > Documentation/rev-list-options.txt | 5 ++++ > > combine-diff.c | 42 ++++++++++++++++++++++++++---- > > diff.h | 1 + > > revision.c | 7 +++++ > > revision.h | 1 + > > 7 files changed, 78 insertions(+), 10 deletions(-) > > I think it might be nice to see a test for this option so that we avoid > breaking it in the future. I'm also curious how this works with -z, and > a test for that would be interesting as well (as well as illustrative of > the format). For example, is it still unambiguous for machine parsing, > even with oddly named files? I'll add a test for both with and without -z.
