Re: Strange behaviour of git diff branch1 ... branch2
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Sat, Oct 27, 2012 at 7:33 PM, Junio C Hamano gits...@pobox.com wrote: Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: Notice the --cc in the first line, which is combined diff. Usually combined-diff is between two points and one parent. Though somehow git passes 4 parents down combined-diff.c:show_combined_header, as you can see in the index line. I think we should fix rev parsing code as it does not make sense to pass 4 identical parents this way. The two heads home from HEAD...HEAD the user has on the command line. The user is getting exactly what she asked; there is nothing to fix. Is there any use case where HEAD...HEAD (or ... alone) is actually useful? That is an invalid question, implying a proposal that will introduce more confusion to the users while hurting the code. There is no use case where cat A A is actually useful, either, but it does not mean cat A A should be special cased to do something different from what it happens to do in line with the case where cat A B does. I think diff ... or diff HEAD...HEAD are the same as that example. -- 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
Re: Strange behaviour of git diff branch1 ... branch2
On Sat, Oct 27, 2012 at 7:33 PM, Junio C Hamano gits...@pobox.com wrote: Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: Notice the --cc in the first line, which is combined diff. Usually combined-diff is between two points and one parent. Though somehow git passes 4 parents down combined-diff.c:show_combined_header, as you can see in the index line. I think we should fix rev parsing code as it does not make sense to pass 4 identical parents this way. The two heads home from HEAD...HEAD the user has on the command line. The user is getting exactly what she asked; there is nothing to fix. Is there any use case where HEAD...HEAD (or ... alone) is actually useful? I have re-read the git-diff man page and I don't think it explains git diff foo ... bar syntax (from a user's point of view, not a git guru's). We could improve the documentation if git diff foo ... bar is useful, or reject it with an error to avoid confusion. -- Duy -- 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
Re: Strange behaviour of git diff branch1 ... branch2
On Sat, Oct 27, 2012 at 4:26 AM, Aaron Schrab aa...@schrab.com wrote: I came across this odd question on stackoverflow: http://stackoverflow.com/q/13092854/1507392 If git diff is run with ... as a separate argument between two commit-ish arguments causes it to produce strange output. The differences seem to be the same as if ... was left out, but change lines begin with 4 + or - characters rather than just 1. Can anybody explain what is happening here? I don't have any reason to want to use that form myself, but I'm very curious about why it produces this odd output. I'm curious too. It shows this to me diff --cc .gitignore index a188a82,a188a82,a188a82,a188a82..d4473d8 --- a/.gitignore +++ b/.gitignore @ -2,9 -2,9 -2,9 -2,9 +2,6 @ /GIT-CFLAGS /GIT-LDFLAGS /GIT-GUI-VARS /GIT-PREFIX /GIT-SCRIPT-DEFINES /GIT-USER-AGENT /GIT-VERSION-FILE /bin-wrappers/ /git Notice the --cc in the first line, which is combined diff. Usually combined-diff is between two points and one parent. Though somehow git passes 4 parents down combined-diff.c:show_combined_header, as you can see in the index line. I think we should fix rev parsing code as it does not make sense to pass 4 identical parents this way. -- Duy -- 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
