On 07/05/2018 09:48, Jeff King wrote: > > > > Let's, please, not fall into the trap of polluting git-branch with > > > utterly unrelated functionality, as has happened a few times with > > > other Git commands. Let's especially not do so merely for the sake of > > > tab-completion. git-branch is for branch management; it's not for > > > diff'ing. > > > > I totally disagree. `git branch` is *the* command to work with branches. > > Yes, you can manage branches. But you can also list them. And now you can > > also compare them. > > One of the things I don't like about "git branch --diff" is that this > feature is not _just_ about branches at all. E.g., I could do: > > git tbdiff HEAD~10 HEAD~5 foo > > Or even: > > git tbdiff v2.16.0 v2.17.0 my-rewritten-v2.17.0 > > Those arguments really are just commitishes, not necessarily branches. > One of the current interface rules for "git branch" is that the branch > names we hand it are interpreted _exactly_ as branch names. You cannot > "git branch -m v2.16.0", and there is no ambiguity in "git branch -d > foo" if "foo" is both a tag and a branch. > > But this new mode does not fit the pattern at all. > > If we were to attach this to an existing command, I think it has more to > do with "diff" than "branch". But I'm not sure we want to overload > "diff" either (which has traditionally been about two endpoints, and > does not really traverse at all, though arguably "foo...bar" is a bit of > a cheat :) ). > > > > Of the suggestions thus far, Junio's git-topic-diff seems the least > > > worse, and doesn't suffer from tab-completion problems. > > > > Except that this is too limited a view. > > Right, I agree with you. Topic branches are the intended use, but that's > not what it _does_, and obviously it can be applied in other cases. So > since "branch" is too specific, I think "topic branch" is even more so. > > It's really "diff-history" or something, I think. That's not very > catchy, but I think the best name would imply that it was diffing a set > of commits (so even "diff-commit" would not be right, because that again > sounds like endpoints).
This is exactly what I feel as well, thanks for concise and to-the-point spelling out. >From user interface perspective, I would expect something like this to be possible (and natural): (1) git diff topic-v1...topic-v2 (2) git diff --branch topic-v1...topic-v2 (1) is what we are all familiar with, providing a diff between two revisions with focus on file changes, where (2) shifts focus to history changes. 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. Hmm... what about `git diff --history`? :/ It does seem more "true" to what it does, though I still like `git diff --branch` more (catchier, indeed). Regards, Buga
