On Mon, May 21, 2018 at 10:56:47AM -0700, Stefan Beller wrote: > > It is very much about > > comparing two *ranges of* revisions, and not just any ranges, no. Those > > ranges need to be so related as to contain mostly identical changes. > > range-diff, eh? > > > Most fellow German software engineers (who seem to have a knack for > > idiotically long variable/function names) would now probably suggest: > > > > git compare-patch-series-with-revised-patch-series > > or short: > > revision-compare > compare-revs > com-revs > > revised-diff > revise-diff > revised-compare > > diff-revise I still like "range diff", but I think something around "revise" is a good line of thought, too. Because it implies that we expect the two ranges to be composed of almost-the-same commits. That leads to another use case where I think focusing on topic branches (or even branches at all) would be a misnomer. Imagine I cherry-pick a bunch of commits with: git cherry-pick -10 $old_commit I might then want to see how the result differs with something like: git range-diff $old_commit~10..$old_commit HEAD~10..HEAD I wouldn't think of this as a topic-branch operation, but just as comparing two sequences of commits. I guess "revise" isn't strictly accurate here either, as I'm not revising. But I do assume the two ranges share some kind of mapping of patches. -Peff PS I wish there were a nicer syntax to do that. Perhaps "git range-diff -10 $old_commit HEAD" could work, though occasionally the two ranges are not the same length (e.g., if you ended up skipping one of the cherry-picked commits). Anyway, those kind of niceties can easily come later on top. :)
