{"thread":{"id":"40824","subject":"Three dot notion used inconsitent?","startedAt":"2015-11-18T10:31:17Z","lastAt":"2015-11-20T09:53:09Z","messageCount":4,"participants":["Lars Schneider","Johannes Löthberg","Andreas Schwab","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"273470","messageId":"1CDF2D38-B73A-4C49-BC10-1F3BA1873733@gmail.com","threadId":"40824","inReplyTo":null,"subject":"Three dot notion used inconsitent?","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2015-11-18T10:31:17Z","receivedAt":"2015-11-18T10:31:17Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"Hi,\n\nI just stumbled across the this:\n\ngit diff branchA...branchB\n--> gives me the diff between (the common ancestor of A and B) and B. That means I never see changes on branchA.\n\ngit log branchA...branchB\n--> gives me the commits reachable from A and B. That includes changes from branchA.\n\nIs this because of a design decision that I do not (yet) understand or is this inconsistent for historical reasons?\n\nThanks,\nLars"},{"id":"273472","messageId":"20151118110213.GA24055@zorg.kyriasis.com","threadId":"40824","inReplyTo":"1CDF2D38-B73A-4C49-BC10-1F3BA1873733@gmail.com","subject":"Re: Three dot notion used inconsitent?","fromName":"Johannes Löthberg","fromEmail":"johannes@kyriasis.com","sentAt":"2015-11-18T11:02:13Z","receivedAt":"2015-11-18T11:02:13Z","isPatch":false,"sender":{"key":"johannes@kyriasis.com","avatar":"https://gravatar.com/avatar/af2dea1b1759403329a1b7eaa28a07b5c5d1901e9f55723103d6324ffb7737ae?d=mp&s=160"},"body":"On 18/11, Lars Schneider wrote:\n>git diff branchA...branchB\n>--> gives me the diff between (the common ancestor of A and B) and B. That means I never see changes on branchA.\n>\n>git log branchA...branchB\n>--> gives me the commits reachable from A and B. That includes changes from branchA.\n>\n>Is this because of a design decision that I do not (yet) understand or is this inconsistent for historical reasons?\n>\n\nThe standard meaning of A...B is all the commits reachable from A or B, \nbut not from both. (See gitrevisions(7) for more info.)\n\ngit-diff has its own nonstandard definition, where A...B is defined as \nall the commits from a comman ancestor of A and B, up to B.\n\n-- \nSincerely,\n Johannes Löthberg\n PGP Key ID: 0x50FB9B273A9D0BB5\n https://theos.kyriasis.com/~kyrias/\n"},{"id":"273479","messageId":"87lh9vp59u.fsf@igel.home","threadId":"40824","inReplyTo":"1CDF2D38-B73A-4C49-BC10-1F3BA1873733@gmail.com","subject":"Re: Three dot notion used inconsitent?","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2015-11-18T17:49:01Z","receivedAt":"2015-11-18T17:49:01Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Lars Schneider writes:\n\n> git diff branchA...branchB\n> --> gives me the diff between (the common ancestor of A and B) and B. That means I never see changes on branchA.\n>\n> git log branchA...branchB\n> --> gives me the commits reachable from A and B. That includes changes from branchA.\n>\n> Is this because of a design decision that I do not (yet) understand or is this inconsistent for historical reasons?\n\ngit diff operates on two revisions. That is inherently incompatible\nwith the usual meaning of A...B and A..B, which are set operations on\nthe revision history. That git diff accepts this syntax is only for\nconvenience.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"273528","messageId":"564EED85.3080706@drmicha.warpmail.net","threadId":"40824","inReplyTo":"87lh9vp59u.fsf@igel.home","subject":"Re: Three dot notion used inconsitent?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-11-20T09:53:09Z","receivedAt":"2015-11-20T09:53:09Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Andreas Schwab venit, vidit, dixit 18.11.2015 18:49:\n> Lars Schneider writes:\n> \n>> git diff branchA...branchB\n>> --> gives me the diff between (the common ancestor of A and B) and B. That means I never see changes on branchA.\n>>\n>> git log branchA...branchB\n>> --> gives me the commits reachable from A and B. That includes changes from branchA.\n>>\n>> Is this because of a design decision that I do not (yet) understand or is this inconsistent for historical reasons?\n> \n> git diff operates on two revisions. That is inherently incompatible\n> with the usual meaning of A...B and A..B, which are set operations on\n> the revision history. That git diff accepts this syntax is only for\n> convenience.\n\nThat convenience can be a bit misleading, though, as the OP points out.\nJust to spell this out because the other response (not the one I'm\nreplying to) could be misunderstood:\n\ngit diff A..B is the diff between (the trees in commits) A and B. It\nwill show you the \"changes\" that are only in A with \"-\", the changes\nthat are only in B with \"+\" - that is, if you want to think about diffs\nas \"positive changes\" to a \"virtual common base tree\".\n\n[ If p are the plus lines and m the minus lines, the diff says\n B = A + p - m = (A-m) + p\n<=> A = B - p + m = (B-p) + m\n<=> B-p = A-m (virtual common base tree) ]\n\ngit log A..B will show you all commits that are in (=reachable from) B\nbut not in A. That is, it will show you all commits between the \"most\nrecent\" common ancestor (let's call it C) and B (including B), but not\nthose between C and A (and not A either).\n\ngit log A...B will show you all commits \"specific to A and B\", i.e.\nthose between C and B and those between C and A (including A and B,\nexcluding C).\n\ngit diff A...B will show you the diff between C and B.\n\nSo, both \"diff A..B\" and \"log A...B\" show changes/commits introduced by\nA only or B only.\n\n\"diff A...B\" and \"log A..B\" show changes/commits introduced by B only.\n\nMaybe there's a way to think about these that makes them actually look\nconsistent - the only one that I can think of is the actual\nimplementation (we need to compute the merge base for both \"...\"\ncommands), but that's a really bad argument for a user facing notation.\n\nMichael\n"}]}