Hi Johannes, >> (2) git diff --branch topic-v1...topic-v2 > > From my point of view, `git diff --branch` indicates that I diff > *branches*. Which is not really something that makes sense, and definitely > not what this command is about. > > We are not comparing branches. > > We are comparing versions of the same branch. I happen to have a messier workflow than you have, as I develop a "resend" of a topic in a new branch (or I have to restore the old sent topic from the reflog). Now that I have the tool I also compare two branches, namely, the branch that Junio queued (origin/base..origin/sb/intelligent-name) vs the resend that I had locally (origin/base..foo). Next time I might compare Junios queued topic to the local format-patch'es that I already annotated. So in a way this diffs different versions of a topic, "diff-topic-versions". >> It`s all still a comparison between two revisions (pointed to by >> "topic-v1" and "topic-v2" branch heads in this specific example), but >> it differs in what we are comparing - (1) set of files contained in >> endpoints, or (2) set of revisions contained in (or "leading to") >> endpoints. > > It is very much not about comparing *two* revisions. I wonder if we can make the tool more intelligent to take two revisions and it figures out the range by finding the base branch itself. Probably as a follow up. > 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 hope you agree that that is better *and* worse than your suggestions, > depending from what angle you look at it: it is better because it > describes what the command is *actually* doing. But it is much worse at > the same time because it is too long. btw, you think very much in terms of *patch series*, but there are workflows without patches (pull requests at Github et Al., changes in Gerrit), and I would think the output of the tool under discussion would still be useful. In [1] Junio gives his use case, it is "before accepting them", which could be comparing an mbox or patch files against a branch, or first building up a local history on a detached head (and then wondering if to reset the branch to the new history), which would be all in Git. That use case still has 'patches' involved, but these are not the main selling point for the tool, as you could turn patches into commits before using this tool. [1] https://public-inbox.org/git/xmqqvabh1ung.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx/ Thanks, Stefan
