Jeff King <p...@peff.net> writes: > One of the things I don't like about "git branch --diff" is that this > feature is not _just_ about branches at all.
I actually wouldn't be that much against the word "branch" in "branch-diff" on the ground that we are typically not feeding branches to the command (we are feeding two ranges, and one endpoint of each range typically gets expressed using branch name), as we have a precedent in "show-branch", for example, that often takes branches but does not have to. > 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). Sure. This should't be a submode "--diff" of "git branch" just like it shouldn't be a submode of "git commit" only because it is about comparing two sets of commits. "diff" is about comparing two endpoints, and not about comparing two sets. "log" is the closest thing, if we really want to coerce it into an existing set of commands, as it is about a set of commits, but it does not do multiple sets, let alone comparing them. "branch-diff" was just a good as "diff-history", except that both of them may irritate command line completion users. I do not think I care too much about which exact command name it gets, but I think it is a bad idea to tacked it to an existing command as a submode that does unrelated thing to what the main command does. So from that point of view, "branch-diff" and "diff-history" are equally good being a distinct command, and equally bad sharing prefix with common existing command.
