Ramkumar Ramachandra wrote: > 3. Even though I lashed out strongly against 'git diff A..B' because > of inconsistency, I can't say that it's not useful (omit specifying > HEAD on one side). If we were to start over today, I would argue that > 'git diff A ^B' and 'git diff B ^A' be handled as special cases to > mean 'git diff B $(git merge-base A B)' and 'git diff $(git merge-base > A B) B' respectively. The normal 'git diff A B' should have nothing > to do with this. Plus, 'git diff A...B' is really an eyesore. So I > ask again: what can be done to improve the situation?
Okay, so my solution to this is: 1. Change the meaning of 'git diff A..B' (and A ^B, ^A B for consistency). Existing users might be using 'git diff master..' on their feature branches to get meaningful output, and this will not change. 'git diff featurebranch1..' on another feature branch doesn't give meaningful output anyway, and I find it hard to believe that users will complain if we change the meaning of this. Okay, maybe we want to do it in git 2.0? 2. Document (1) properly in gitrevisions.txt. 3. Deprecate 'git diff A...B'. What do you think? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
