On Mon, May 7, 2018 at 3:05 PM, Igor Djordjevic <igor.d.djordjevic@xxxxxxxxx> wrote: > List, rename, delete -- all these seem more as basic CRUD operations, > where comparison is a more complex one. And not to get me wrong - I > could see "branch diff" being part of "branch", but not really when > "diff" already exists as a separate thing, already doing quite some > (but still diff related, and configurable) stuff. If we go with "branch --diff", because it has the CRUD operations already there for branches, I might ask for "remote --diff" to diff two remotes. ;) (That command "remote --diff" would not make any sense, would it?) > Basically, what you (conceptually) call "two versions of the same > branch", I simply call "two branches" (from usage standpoint). If I diff 2 (topic) branches, which are based on a different version from upstream, then I see changes from commits that I don't care about, but this tool explicitly excludes them. Instead it includes the ordering of the commits as well as its commit messages to the diff. So I would not say this tool "diffs two branches", as that is understood as "diffing the trees, where each of the two branches points two", whereas this tool diffs a patch series, or if you give Git-ranges, then it would produce such a patch series in memory. > And you may have a branch that got split, or more of them that got > unified, so defining "previous branch version" may not be that > straightforward - it`s really just "two commit ranges" (as man page > defines it in general), with "two versions of a patch series" only > being the most common/expected use case of the former. > > Finally, if user picks two totally unrelated "branches" to compare, > he won`t get a really useful diff - but it`s the same as if he would > compare two totally unrelated commits (where tree state massively > changed in between, or having unrelated histories, even). I used just that, but narrowed down the comparison to one file instead of the whole tree. > With something like `git diff --branch <commit1>...<commit2>` you > would get yet another "diff look", useful for use case in question > here. Personally I think this patch series should neither extend git-diff nor git-branch. It should not extend git-diff, because currently git-diff can diff tree-ishs (and does that very well) and comparing to worktree/index. It should also not extend git-branch, as that command is for CRUD operations that you hinted at earlier (Earlier I proposed git-remote --diff for diffing two remote, which makes no sense, another one might be git-worktree, which also just does CRUD for worktrees. It would be a bad idea to have "git worktree --diff") Hence I propose "git range-diff", similar to topic-diff, that was proposed earlier. * it "diffs ranges" of commits. * it can also deal with out-of-git things like patch series, but that is a mere by product and may not be desired. Just like git-diff can also compare two files outside a git repo, that would not be a good use case. Keep the name Git-centric! * it autocompletes well. Stefan
