Johannes, On IRC you wrote: <dscho> And BTW this is not bike-shedding to me. Discussing the name of a variable, or indentation, or line wrapping, is. But improving the user experience is important. We *suck* on that, historically, and I do want to break with that habit. ... <dscho> avar, _ikke_: so a colleague of mine whose opinion on naming I respect more than all Git developers combined *also* came up with the term `range-diff`, independently. ... <dscho> Yes, you are looking at two ranges. But not *any* two ranges. *That* is my point. So I sat back and want to try again; IIUC your dislike for "range-diff" boils down to: (A) it doesn't diff any arbitrary range, as the output would become very cumbersome and hard to understand, (B) it is not a good intuitive name for users, as they would not think of range-diff when they'd want to have this feature. Regarding (A), I think the same can be said about input to the diff machinery, e.g. 'git diff v2.0.0 v2.17.0' is just very much text, and it is hardly useful (except as a patch fed to the machine). Over time there were added tons of options that make the diff output easier to digest, e.g. additional pathspecs to restrict to a sub tree or ignoring certain things (white spaces mostly), such that 'git diff -w v2.0.0 v2.17.0 -- refs.h' is easier for a human to grok. Regarding (B), I agree, but blame it on the nature of an open source project that provides a toolbox. So the way a user is going to discover this feature is via stackoverflow or via asking a coworker or finding the example output somewhere. I think that last point could be part of the feedback: git-diff has prominently hints at its name via "diff --git ..." in the first line of its output, so maybe the output of this feature also wants to name itself? Other thoughts: We could go down the route and trying to find a best possible technical name, for which I could offer: revision-walk-difference revwalk-diff As that literally describes the output: two rev walks are performed and then those outputs of the rev walks is diffed. Based off these technicals we could get more creative: redo-rev-walk-spot-the-difference re-walk-spot retravel-spot spot-diff But I think all these do not address the feedback (B). "What would a user find intuitive?"; I personally thought a bit about how I discovered cherry-pick. I just took it as a given name, without much thought, as I discovered it by tell tale, not looking for it in the docs. It sort of made sense as a command that I learned earlier about, "interactive rebase", also has had the "pick" command, such that "picking" made sense. I think I retroactively made sense of the "cherry" part. Now I tried to find it in the mailing list archive and actually learn about its origin, but no good stories are found there. For what the user might find most useful, I just looked at other tools in Gerrits landscape and there the expectation seems that you upload your code first and do the diff of the different patches serverside. I think the same holds for Github or other branch based reviewing systems. You can force push the branch that is pull requested and the web UI somehow makes sense of it. That leads me to the (weak) conclusion of branch-diff or tbdiff to be useful most for patch based / mailing list based workflows as there is no magic server helping you out. Searching for "kernel +tbdiff" to find the kernel devs using tbdiff gave me no results, so I may be mistaken there. Trying to find "interdiffs" (for the lack of a better name) between patches on the kernel mailing list also is not obvious to the uninitiated. So for the various workflows, I could come up with change-diff pullrequest-diff patch-series-diff but we do not look at diffs, rather we only use this tool to work on incremental things, so maybe instead: change-history pullrequest-history patch-series-evolution Note how these are 3 suggestions, one for each major workflow, and I'd *REALLY* would want to have a tool that is agnostic to the workflow on top (whether you use pull requests or Gerrit changes), but now I would like to step back and remind us that this tool is only mostly used for viewing the evolution of your new thing, but it can also be very useful to inspect non-new things. (backported patches to maint, or some -stable branch) Or rather: We do not know the major use case yet. Sure I will use it in my cover letter and that is on my mind now, but I think there are other use cases that are not explored yet, so we should rather make the naming decision based off of technicals rather than anticipated use case and user discovery methods. I hope this is actually useful feedback on the naming discovery. Thanks, Stefan
