{"thread":{"id":"13298","subject":"my git problem","startedAt":"2008-04-27T18:29:38Z","lastAt":"2008-05-01T06:01:32Z","messageCount":21,"participants":["Andrew Morton","Linus Torvalds","Johannes Schindelin","Daniel Barkalow","J. Bruce Fields","Jakub Narebski","Carl Worth"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"75320","messageId":"20080427112938.4dbe8e2a.akpm@linux-foundation.org","threadId":"13298","inReplyTo":null,"subject":"my git problem","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-04-27T18:29:38Z","receivedAt":"2008-04-27T18:29:38Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"\ngit is really really bad to me during the merge window.  Let's look at an\nexample:\n\ny:/usr/src/git26> cat .git/branches/git-ia64 \ngit+ssh://master.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git#test\n\nNow, I want to generate a plain patch against mainline which will add the\npatches which are in git-ia64 and which aren't in mainline.  ie: when that\npatch is applied to mainline, we get git-ia64.  Sounds simple.\n\nA naive\n\n\tgit-diff origin git-ia64\n\ngenerates vast amounts of stuff which is already in mainline.  Things like\n\n b/drivers/media/video/au0828/au0828-dvb.c       |    2 \n b/drivers/media/video/au0828/au0828-i2c.c       |    6 \n b/drivers/media/video/au0828/au0828.h           |    8 \n b/drivers/media/video/cx23885/cx23885-dvb.c     |    4 \n b/drivers/media/video/cx88/Kconfig              |    1 \n b/drivers/media/video/cx88/cx88-blackbird.c     |    6 \n b/drivers/media/video/cx88/cx88-cards.c         |    1 \n b/drivers/media/video/cx88/cx88-dvb.c           |   32 \n b/drivers/media/video/em28xx/em28xx-core.c      |    2 \n b/drivers/media/video/ir-kbd-i2c.c              |   21 \n b/drivers/media/video/pvrusb2/Kconfig           |    1 \n\n\nThe appended script is what I usually use.  It was worked out by Junio and\nI maybe a couple of years ago. It doesn't work very well: it still generates\nlarge numbers of changes which are already in mainline.  Some of them are\nia64 changes, some are not.\n\nWhen Tony resyncs his tree with mainline this problem will correct itself. \nI drop the tree and repoll it daily until this happens.\n\n\nI don't really have a bottom line here - but I would like the git\ndevelopers to be aware that what is a fairly sensible usage scenario just\ndoesn't seem to be satisfied at all well...\n\nThanks.\n\n\n\n#!/bin/sh\n\nGIT_TREE=/usr/src/git26\nPULL=/usr/src/pull\n\ngit_header()\n{\n\ttree=\"$1\"\n\techo GIT $(cat .git/refs/heads/$tree) $(cat .git/branches/$tree)\n\techo\n}\n\ndoit()\n{\n\ttree=$1\n\tupstream=$2\n\n\tcd $GIT_TREE\n\tgit reset --hard \"$upstream\"\n\tgit fetch \"$tree\" || exit 1\n\tgit merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null\n\n\t{\n\t\tgit_header \"$tree\"\n\t\tgit log --no-merges ORIG_HEAD..FETCH_HEAD\n\t\tgit diff --patch-with-stat ORIG_HEAD\n\t} >$PULL/$tree.patch\n\t{\n\t\techo DESC\n\t\techo $tree.patch\n\t\techo EDESC\n\t\tgit_header \"$tree\"\n\t\tgit log --no-merges ORIG_HEAD..FETCH_HEAD\n\t} >$PULL/$tree.txt\n\tgit reset --hard \"$upstream\"\n}\n\nmkdir -p $PULL\n\nif [ $1\"x\" = \"-x\" ]\nthen\n\texit\nfi\n\ncd /usr/src\n\nif [ $# == 0 ]\nthen\n\ttrees=/usr/src/git-trees\nelse\n\ttrees=\"$1\"\nfi\n\ndo_one()\n{\n\ttree=$1\n\tupstream=$2\n\tif [ ! -e $PULL/$tree.patch ]\n\tthen\n\t\techo \"*** doing $tree, based on $upstream\"\n\t\tgit-branch -D $tree\n\t\tdoit $tree $upstream\n\telse\n\t\techo skipping $tree\n\tfi\n}\n\t\nif [ $# == 2 ]\nthen\n\tdo_one $1 $2\nelse\n\twhile read x\n\tdo\n\t\tif echo $x | grep '^#.*' > /dev/null\n\t\tthen\n\t\t\ttrue\n\t\telse\n\t\t\tdo_one $x\n\t\tfi\n\tdone < $trees\nfi\n"},{"id":"75323","messageId":"alpine.LFD.1.10.0804271204510.3119@woody.linux-foundation.org","threadId":"13298","inReplyTo":"20080427112938.4dbe8e2a.akpm@linux-foundation.org","subject":"Re: my git problem","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-04-27T19:15:27Z","receivedAt":"2008-04-27T19:15:27Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 27 Apr 2008, Andrew Morton wrote:\n> \n> Now, I want to generate a plain patch against mainline which will add the\n> patches which are in git-ia64 and which aren't in mainline.  ie: when that\n> patch is applied to mainline, we get git-ia64.  Sounds simple.\n> \n> A naive\n> \n> \tgit-diff origin git-ia64\n\nDon't do that.\n\nThat will diff between the two branches, and if they both contain stuff \n(which they obviously do), you'll get all the things that are in origin \n(but not git-ia64) as a reversed diff.\n\nWhat you _want_ is the diff from the last common point, aka the \"merge \nbase\".\n\nWith git, you could do that as\n\n\tmerge_base=$(git merge-base origin git-ia64)\n\tgit diff $merge_base git-ia64\n\nbut there is a convenient shorthand for that, which is to use \"a...b\" \n(three dots!), so\n\n\tgit diff -p --stat origin...git-ia64\n\nshould generally get you what you want.\n\nI say *generally*, because there might be multiple merge-bases if there \nare crossing merges between the two branches and there is no well-defined \nsingle common point. But that criss-cross case almost never happens for \nthe kernel, because I've been pretty good at trying to teach maintainers \nto not generate that kind of complex history (it doesn't just obfuscate \nthe above kind of situation, it also makes gitk output harder-to-read than \nit otherwise would be).\n\nThat said, your script (that does a merge) should have been able to get \nthe diff too, and in fact handle even the criss-cross case. It's written a \nbit strangely (like having that really old-fashioned way of using git \nmerge, passing in HEAD explicitly etc).\n\n\t\t\tLinus\n"},{"id":"75324","messageId":"20080427124454.6a606305.akpm@linux-foundation.org","threadId":"13298","inReplyTo":"alpine.LFD.1.10.0804271204510.3119@woody.linux-foundation.org","subject":"Re: my git problem","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-04-27T19:44:54Z","receivedAt":"2008-04-27T19:44:54Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Sun, 27 Apr 2008 12:15:27 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:\n\n> \n> \n> On Sun, 27 Apr 2008, Andrew Morton wrote:\n> > \n> > Now, I want to generate a plain patch against mainline which will add the\n> > patches which are in git-ia64 and which aren't in mainline.  ie: when that\n> > patch is applied to mainline, we get git-ia64.  Sounds simple.\n> > \n> > A naive\n> > \n> > \tgit-diff origin git-ia64\n> \n> Don't do that.\n> \n> That will diff between the two branches, and if they both contain stuff \n> (which they obviously do), you'll get all the things that are in origin \n> (but not git-ia64) as a reversed diff.\n> \n> What you _want_ is the diff from the last common point, aka the \"merge \n> base\".\n> \n> With git, you could do that as\n> \n> \tmerge_base=$(git merge-base origin git-ia64)\n> \tgit diff $merge_base git-ia64\n> \n> but there is a convenient shorthand for that, which is to use \"a...b\" \n> (three dots!), so\n> \n> \tgit diff -p --stat origin...git-ia64\n> \n> should generally get you what you want.\n\nThat generates no diff for several trees which I tried it on.  And\nafaict from manual inspection, that's correct - they are empty.\n\ngit-sched is non-empty:\n\ny:/usr/src/git26> cat .git/branches/git-sched \ngit+ssh://master.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git#for-akpm\n\nand seems to dtrt too.\n\nBut I'm pretty sure that the simple solutions were found wanting, but I\ndon't recall why.  I think it was because of a problem when\ngit-netdev-all is based on git-net which is based on origin.  I want to\nextract the git-net -> git-netdev-all diff, but doing that generates\npatches which reapply things which are already applied.\n\niirc this happens when git-netdev-all is resynced with origin at a\ndifferent time from when git-net is resynced with origin.  I get hunks\nwhich reapply (or revert) changes which are in origin.\n\nBut I don't presently have any trees which are based on other non-origin\ntrees so I can't test that.\n\n> I say *generally*, because there might be multiple merge-bases if there \n> are crossing merges between the two branches and there is no well-defined \n> single common point. But that criss-cross case almost never happens for \n> the kernel, because I've been pretty good at trying to teach maintainers \n> to not generate that kind of complex history (it doesn't just obfuscate \n> the above kind of situation, it also makes gitk output harder-to-read than \n> it otherwise would be).\n> \n> That said, your script (that does a merge) should have been able to get \n> the diff too, and in fact handle even the criss-cross case. It's written a \n> bit strangely (like having that really old-fashioned way of using git \n> merge, passing in HEAD explicitly etc).\n\nWell.  It is a couple of years old.\n\nI'll try the simple version later, see what happens.  Thanks.\n"},{"id":"75328","messageId":"alpine.LFD.1.10.0804271315010.3119@woody.linux-foundation.org","threadId":"13298","inReplyTo":"20080427124454.6a606305.akpm@linux-foundation.org","subject":"Re: my git problem","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-04-27T20:24:08Z","receivedAt":"2008-04-27T20:24:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 27 Apr 2008, Andrew Morton wrote:\n> \n> But I'm pretty sure that the simple solutions were found wanting, but I\n> don't recall why.  I think it was because of a problem when\n> git-netdev-all is based on git-net which is based on origin.  I want to\n> extract the git-net -> git-netdev-all diff, but doing that generates\n> patches which reapply things which are already applied.\n\nWell, if a tree has patches that are already applied up-stream, then yes, \nyou do actually have to do the merge in order to see that. Because \nobviously the diff is in two places, and if they merge cleanly, one of \nthem has to be made to not count.\n\nSo it depends on what you want.\n\n\tgit diff a...b\n\nsays literally \"what has been added to 'b' since it diverged from 'a'\". \n\nThat is a useful and valid thing to ask, but it is very fundamentally also \n*not* the same thing as actually doing the merge, and asking what the \nmerge added. Doing\n\n\tgit merge --no-commit otherbranch\n\tgit diff HEAD > diff\n\tgit reset --hard\n\nwill do that: it will do the merge (which obviously squashes any diffs \nthat existed in the other tree as different commits), and then diffs the \nHEAD against that resulting state.\n\nSo they are two fundamentally different things to do.\n\nIn some sense, the \"git diff a...b\" is closer to your \"series of quilt \npatches\" model, in that it just generates a patch - which may obviously \nconflict with the *other* patches you are also generating. It would then \nexpect your quilt logic to do some sane patch merging.\n\nOf course, we know that quilt doesn't do sane patch merging, so you are \nprobably better off with the second version: letting git merge for you, \nand taking the resulting diff.\n\n> But I don't presently have any trees which are based on other non-origin\n> trees so I can't test that.\n\nYes, in that case you'll only get issues when somebody commits the same \npatch I have already applied. Which does happen, of course.\n\n\t\t\tLinus\n"},{"id":"75424","messageId":"20080428114509.240ef4ae.akpm@linux-foundation.org","threadId":"13298","inReplyTo":"alpine.LFD.1.10.0804271315010.3119@woody.linux-foundation.org","subject":"Re: my git problem","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-04-28T18:45:09Z","receivedAt":"2008-04-28T18:45:09Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Sun, 27 Apr 2008 13:24:08 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:\n\n> \n> \n> On Sun, 27 Apr 2008, Andrew Morton wrote:\n> > \n> > But I'm pretty sure that the simple solutions were found wanting, but I\n> > don't recall why.  I think it was because of a problem when\n> > git-netdev-all is based on git-net which is based on origin.  I want to\n> > extract the git-net -> git-netdev-all diff, but doing that generates\n> > patches which reapply things which are already applied.\n> \n> Well, if a tree has patches that are already applied up-stream, then yes, \n> you do actually have to do the merge in order to see that. Because \n> obviously the diff is in two places, and if they merge cleanly, one of \n> them has to be made to not count.\n> \n> So it depends on what you want.\n> \n> \tgit diff a...b\n> \n> says literally \"what has been added to 'b' since it diverged from 'a'\". \n> \n> That is a useful and valid thing to ask, but it is very fundamentally also \n> *not* the same thing as actually doing the merge, and asking what the \n> merge added. Doing\n> \n> \tgit merge --no-commit otherbranch\n> \tgit diff HEAD > diff\n> \tgit reset --hard\n> \n> will do that: it will do the merge (which obviously squashes any diffs \n> that existed in the other tree as different commits), and then diffs the \n> HEAD against that resulting state.\n> \n\nhm, weirdness.\n\ny:/usr/src/git26> git-diff origin...git-ia64   \ny:/usr/src/git26> git-log origin...git-ia64 | wc -l\n15574\n\nI'd have expected git-log to operate on the same patches as git-diff.\n\nI'm sure there's a logical explanation for this ;)\n"},{"id":"75426","messageId":"alpine.DEB.1.00.0804281948270.19187@eeepc-johanness","threadId":"13298","inReplyTo":"20080428114509.240ef4ae.akpm@linux-foundation.org","subject":"Re: my git problem","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-28T18:49:28Z","receivedAt":"2008-04-28T18:49:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 28 Apr 2008, Andrew Morton wrote:\n\n> hm, weirdness.\n> \n> y:/usr/src/git26> git-diff origin...git-ia64   \n> y:/usr/src/git26> git-log origin...git-ia64 | wc -l\n> 15574\n> \n> I'd have expected git-log to operate on the same patches as git-diff.\n> \n> I'm sure there's a logical explanation for this ;)\n\nYes.  git-diff with \"...\" will show you the diff of git-ia64 since the \nbranch point, whereas log will show you _all_ the logs (both in origin and \nin git-ia64) since the branch point.\n\nCiao,\nDscho\n"},{"id":"75431","messageId":"20080428120917.dd9f01e8.akpm@linux-foundation.org","threadId":"13298","inReplyTo":"alpine.DEB.1.00.0804281948270.19187@eeepc-johanness","subject":"Re: my git problem","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-04-28T19:09:17Z","receivedAt":"2008-04-28T19:09:17Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Mon, 28 Apr 2008 19:49:28 +0100 (BST) Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n\n> Hi,\n> \n> On Mon, 28 Apr 2008, Andrew Morton wrote:\n> \n> > hm, weirdness.\n> > \n> > y:/usr/src/git26> git-diff origin...git-ia64   \n> > y:/usr/src/git26> git-log origin...git-ia64 | wc -l\n> > 15574\n> > \n> > I'd have expected git-log to operate on the same patches as git-diff.\n> > \n> > I'm sure there's a logical explanation for this ;)\n> \n> Yes.  git-diff with \"...\" will show you the diff of git-ia64 since the \n> branch point, whereas log will show you _all_ the logs (both in origin and \n> in git-ia64) since the branch point.\n> \n\nThat's missing the \"logical\" bit :)\n\nOh well.  Can you suggest how I can extract the changelogs for the patches\nwhich `git-diff origin...git-ia64' will print out?\n\nThanks.\n"},{"id":"75434","messageId":"alpine.DEB.1.00.0804282012140.19187@eeepc-johanness","threadId":"13298","inReplyTo":"20080428120917.dd9f01e8.akpm@linux-foundation.org","subject":"Re: my git problem","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-28T19:13:43Z","receivedAt":"2008-04-28T19:13:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 28 Apr 2008, Andrew Morton wrote:\n\n> On Mon, 28 Apr 2008 19:49:28 +0100 (BST) Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> \n> > On Mon, 28 Apr 2008, Andrew Morton wrote:\n> > \n> > > hm, weirdness.\n> > > \n> > > y:/usr/src/git26> git-diff origin...git-ia64   \n> > > y:/usr/src/git26> git-log origin...git-ia64 | wc -l\n> > > 15574\n> > > \n> > > I'd have expected git-log to operate on the same patches as git-diff.\n> > > \n> > > I'm sure there's a logical explanation for this ;)\n> > \n> > Yes.  git-diff with \"...\" will show you the diff of git-ia64 since the \n> > branch point, whereas log will show you _all_ the logs (both in origin and \n> > in git-ia64) since the branch point.\n> > \n> \n> That's missing the \"logical\" bit :)\n\nHeh, you're right.  I am too used to Git to think how other people would \nfeel about these things... :-)\n\n> Oh well.  Can you suggest how I can extract the changelogs for the \n> patches which `git-diff origin...git-ia64' will print out?\n\nI think you get what you want with\n\n\t$ git-log --cherry-pick origin...git-ia64\n\n(although I might be wrong on the order of origin and git-ia64).\n\nCiao,\nDscho\n"},{"id":"75435","messageId":"alpine.LFD.1.10.0804281200130.3119@woody.linux-foundation.org","threadId":"13298","inReplyTo":"20080428114509.240ef4ae.akpm@linux-foundation.org","subject":"Re: my git problem","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-04-28T19:21:17Z","receivedAt":"2008-04-28T19:21:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 28 Apr 2008, Andrew Morton wrote:\n> \n> hm, weirdness.\n> \n> y:/usr/src/git26> git-diff origin...git-ia64   \n> y:/usr/src/git26> git-log origin...git-ia64 | wc -l\n> 15574\n> \n> I'd have expected git-log to operate on the same patches as git-diff.\n\nNo, not at all.\n\n - \"git log\" shows each commit in a range.\n\n - \"git diff\" shows just the difference between two states.\n\nThe two have nothing in common. One operates on lots of individual commits \n(git log) individually, while the other one fundamentally operates on just \ntwo end-points (git diff).\n\nAnd \"a..b\" and \"a...b\" means two totally different things for the two \ntotally different operations.\n\nWhen doing \"a..b\" and looking at individual commits, it means \"show all \ncommits that are in b but *not* in a\". And when doing \"a..b\" when asking \nfor a \"diff\", it means \"show the difference from 'a' to 'b'\".\n\nThey are *very* different operations indeed. The log can be empty, even if \nthe diff is not empty (example: b is _before_ a, so there is nothing in \n'b' that isn't in 'a', but that doesn't mean that 'b' is *equal* to 'a', \nso there is still a diff!). And the log can be non-empty, even if the diff \nis empty (example: 'b' and 'a' have the same actual tree, but two \ndifferent ways of gettign there: the diff is empty, but the log of commits \nin between them is not).\n\nSo anybody who thinks that 'diff' and 'log' have *anything* to do with \neach other is fundamentally confused. Not just about git, btw. It's true \nin any model - it's fundamental.\n\nAs to 'a...b', it also means somethign different for diff (two endpoints!) \nand log (set of commits). For diff, it means \"show the difference between \nthe common commit and 'b'\", while for log it means \"show all commits that \nare in either 'a' or 'b' but *not* in both\".\n\nSo you should do\n\n\t# generate the diff from the common point\n\tgit diff -p --stat a...b\n\n\t# show the commits that are in b but not in a\n\tgit log a..b\n\nwhere the difference between two dots and three dots is important, and \nstems directly from the fact that 'diff' and 'log' are two totally \ndifferent operations that cannot _possibly_ have semantics that mean the \nsame thing - because a \"set of commits\" is fundamentally different from \n\"difference betwen two endpoints\".\n\nSo both \"a..b\" and \"a...b\" have meaning for both diff and log, but which \nyou want to use depends on what you are looking for.\n\nThey do have some relationship, of course. If you want to have a simple \nway to know which is which, then\n\n - \"a..b\" is a plain difference. Think of it as a subtraction. For \"diff\", \n   it is simply the diff between a and b, and for log it is the \"set \n   difference\" (shown as either just \"-\" or as \"\\\" in set theory math) \n   between the commits that are in b and not in a.\n\n - \"a...b\" is a more complex difference. For log, it's no longer the \n   regular set difference, but a \"symmetric difference\" (usually shown as \n   a greek capital \"Delta\" in set theory math). And for \"diff\", it's no \n   longer just the diff between two states, it's the diff from a third \n   state (the nearest common state) to the second state.\n\nIn short: It's easy to think that \"log\" and \"diff\" are related, but they \nreally are very fundamnetally different. \n\n\t\tLinus\n"},{"id":"75438","messageId":"alpine.LFD.1.10.0804281222190.3119@woody.linux-foundation.org","threadId":"13298","inReplyTo":"alpine.DEB.1.00.0804282012140.19187@eeepc-johanness","subject":"Re: my git problem","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-04-28T19:28:38Z","receivedAt":"2008-04-28T19:28:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 28 Apr 2008, Johannes Schindelin wrote:\n> \n> On Mon, 28 Apr 2008, Andrew Morton wrote:\n> > \n> > That's missing the \"logical\" bit :)\n> \n> Heh, you're right.  I am too used to Git to think how other people would \n> feel about these things... :-)\n\nNo, you are both wrong.\n\nYou're wrong because apparently you never did abstract algebra and set \ntheory in school.\n\nIf you know math, git actually does the rigth and very much the *logical* \nthing.\n\nSo \"..\" is a simple difference, while \"...\" is a more complex difference. \n\nThey mean different things for different operation types, but that is \nagain something a math person takes for granted (ie in algebra, a \"+\" or \n\"-\" is just a random operation that follows certain rules: \"a-b\" means one \nthing for the set of real numbers, and something *totally* different if \nyou are talking about set algebra).\n\nAnd \"diff\" and \"log\" really are different operation types, exactly in the \nsense that \"operations on real numbers\" are different from \"set \noperations\".\n\nA \"diff\" is more like a difference between two real numbers: it gives a \nsingle answer (admittedly the single answer is in a different domain from \nthe arguments). While \"log\" is very close to a set operation, in that it \ngives a set as its result.\n\n\t\tLinus\n"},{"id":"75439","messageId":"20080428123300.f5406ca9.akpm@linux-foundation.org","threadId":"13298","inReplyTo":"alpine.DEB.1.00.0804282012140.19187@eeepc-johanness","subject":"Re: my git problem","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-04-28T19:33:00Z","receivedAt":"2008-04-28T19:33:00Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Mon, 28 Apr 2008 20:13:43 +0100 (BST) Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n\n> > Oh well.  Can you suggest how I can extract the changelogs for the \n> > patches which `git-diff origin...git-ia64' will print out?\n> \n> I think you get what you want with\n> \n> \t$ git-log --cherry-pick origin...git-ia64\n> \n> (although I might be wrong on the order of origin and git-ia64).\n\nNope, that still generates thousands of lines of wrongness.\n\nIt's also very slow, for a non-empty tree:\n\ngit-log --cherry-pick origin...git-audit-master > /dev/null  50.47s user 0.56s system 99% cpu 51.043 total\n\ngit-diff origin...git-audit-master > /dev/null  0.35s user 0.02s system 100% cpu 0.369 total\n\nweird that it's hundreds of times slower than the corresponding git-diff. \nhe-who-pulls-75-trees would be unhappy.\n\nBack to my original problem...\n\n>From my old script:\n\ndoit()\n{\n\ttree=$1\n\tupstream=$2\n\n\tcd $GIT_TREE\n\tgit reset --hard \"$upstream\"\n\tgit fetch \"$tree\" || exit 1\n\tgit merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null\n\n\t{\n\t\tgit_header \"$tree\"\n\t\tgit log --no-merges ORIG_HEAD..FETCH_HEAD\n\t\tgit diff --patch-with-stat ORIG_HEAD\n\t} >$PULL/$tree.patch\n\t{\n\t\techo DESC\n\t\techo $tree.patch\n\t\techo EDESC\n\t\tgit_header \"$tree\"\n\t\tgit log --no-merges ORIG_HEAD..FETCH_HEAD\n\t} >$PULL/$tree.txt\n\tgit reset --hard \"$upstream\"\n}\n\nthe `git log' here does what I want.\n\nThe new version:\n\ndoit()\n{\n\ttree=$1\n\tupstream=$2\n\n\tcd $GIT_TREE\n\tgit reset --hard \"$upstream\"\n\tgit fetch \"$tree\" || exit 1\n\n\t{\n\t\tgit_header \"$tree\"\n\t\tgit log --no-merges $upstream...$tree\n\t\tgit diff -p --stat --no-merges $upstream...$tree\n\t} >$PULL/$tree.patch\n\t{\n\t\techo DESC\n\t\techo $tree.patch\n\t\techo EDESC\n\t\tgit_header \"$tree\"\n#\t\tgit log --no-merges $upstream...$tree\n\t} >$PULL/$tree.txt\n\tgit reset --hard \"$upstream\"\n}\n\nloses the changelogs :(\n"},{"id":"75443","messageId":"alpine.LNX.1.00.0804281537260.19665@iabervon.org","threadId":"13298","inReplyTo":"20080428114509.240ef4ae.akpm@linux-foundation.org","subject":"Re: my git problem","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-04-28T19:52:17Z","receivedAt":"2008-04-28T19:52:17Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 28 Apr 2008, Andrew Morton wrote:\n\n> On Sun, 27 Apr 2008 13:24:08 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:\n> > \n> > On Sun, 27 Apr 2008, Andrew Morton wrote:\n> > > \n> > > But I'm pretty sure that the simple solutions were found wanting, but I\n> > > don't recall why.  I think it was because of a problem when\n> > > git-netdev-all is based on git-net which is based on origin.  I want to\n> > > extract the git-net -> git-netdev-all diff, but doing that generates\n> > > patches which reapply things which are already applied.\n> > \n> > Well, if a tree has patches that are already applied up-stream, then yes, \n> > you do actually have to do the merge in order to see that. Because \n> > obviously the diff is in two places, and if they merge cleanly, one of \n> > them has to be made to not count.\n> > \n> > So it depends on what you want.\n> > \n> > \tgit diff a...b\n> > \n> > says literally \"what has been added to 'b' since it diverged from 'a'\". \n> > \n> > That is a useful and valid thing to ask, but it is very fundamentally also \n> > *not* the same thing as actually doing the merge, and asking what the \n> > merge added. Doing\n> > \n> > \tgit merge --no-commit otherbranch\n> > \tgit diff HEAD > diff\n> > \tgit reset --hard\n> > \n> > will do that: it will do the merge (which obviously squashes any diffs \n> > that existed in the other tree as different commits), and then diffs the \n> > HEAD against that resulting state.\n> > \n> \n> hm, weirdness.\n> \n> y:/usr/src/git26> git-diff origin...git-ia64   \n> y:/usr/src/git26> git-log origin...git-ia64 | wc -l\n> 15574\n> \n> I'd have expected git-log to operate on the same patches as git-diff.\n\nI don't think this operation is even well-defined for git-log. What do you \nexpect to see if origin contains some of the same changes as ia64, but \nwhere what changes are in the same patch are different on the two paths? \nEven more so, what if ia64 has some additional changes in a commit that \nhad other changes that were left out of the origin version?\n\nFor the diff, it doesn't matter, but for log it would.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"75445","messageId":"20080428125400.e91c1c24.akpm@linux-foundation.org","threadId":"13298","inReplyTo":"alpine.LFD.1.10.0804281200130.3119@woody.linux-foundation.org","subject":"Re: my git problem","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-04-28T19:54:00Z","receivedAt":"2008-04-28T19:54:00Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Mon, 28 Apr 2008 12:21:17 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:\n\n> \n> \n> On Mon, 28 Apr 2008, Andrew Morton wrote:\n> > \n> > hm, weirdness.\n> > \n> > y:/usr/src/git26> git-diff origin...git-ia64   \n> > y:/usr/src/git26> git-log origin...git-ia64 | wc -l\n> > 15574\n> > \n> > I'd have expected git-log to operate on the same patches as git-diff.\n> \n> No, not at all.\n> \n>  - \"git log\" shows each commit in a range.\n> \n>  - \"git diff\" shows just the difference between two states.\n> \n> The two have nothing in common. One operates on lots of individual commits \n> (git log) individually, while the other one fundamentally operates on just \n> two end-points (git diff).\n> \n> And \"a..b\" and \"a...b\" means two totally different things for the two \n> totally different operations.\n> \n> When doing \"a..b\" and looking at individual commits, it means \"show all \n> commits that are in b but *not* in a\". And when doing \"a..b\" when asking \n> for a \"diff\", it means \"show the difference from 'a' to 'b'\".\n> \n> They are *very* different operations indeed. The log can be empty, even if \n> the diff is not empty (example: b is _before_ a, so there is nothing in \n> 'b' that isn't in 'a', but that doesn't mean that 'b' is *equal* to 'a', \n> so there is still a diff!). And the log can be non-empty, even if the diff \n> is empty (example: 'b' and 'a' have the same actual tree, but two \n> different ways of gettign there: the diff is empty, but the log of commits \n> in between them is not).\n\nwhimper.\n\n> So anybody who thinks that 'diff' and 'log' have *anything* to do with \n> each other is fundamentally confused.\n\nhi, everyone.\n\n>  Not just about git, btw. It's true \n> in any model - it's fundamental.\n>\n> As to 'a...b', it also means somethign different for diff (two endpoints!) \n> and log (set of commits). For diff, it means \"show the difference between \n> the common commit and 'b'\", while for log it means \"show all commits that \n> are in either 'a' or 'b' but *not* in both\".\n> \n> So you should do\n> \n> \t# generate the diff from the common point\n> \tgit diff -p --stat a...b\n> \n> \t# show the commits that are in b but not in a\n> \tgit log a..b\n\nThat seems to work nicely, thanks.\n\n> where the difference between two dots and three dots is important, and \n> stems directly from the fact that 'diff' and 'log' are two totally \n> different operations that cannot _possibly_ have semantics that mean the \n> same thing - because a \"set of commits\" is fundamentally different from \n> \"difference betwen two endpoints\".\n\nyup.\n"},{"id":"75467","messageId":"20080428143501.7d6e3ad0.akpm@linux-foundation.org","threadId":"13298","inReplyTo":"alpine.LFD.1.10.0804271315010.3119@woody.linux-foundation.org","subject":"Re: my git problem","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-04-28T21:35:01Z","receivedAt":"2008-04-28T21:35:01Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Sun, 27 Apr 2008 13:24:08 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:\n\n> So it depends on what you want.\n> \n> \tgit diff a...b\n> \n> says literally \"what has been added to 'b' since it diverged from 'a'\". \n\nConfounded by Ingo.\n\norigin.patch (generated via git-diff v2.6.25...origin) has:\n\ncommit 7f424a8b08c26dc14ac5c17164014539ac9a5c65\nAuthor: Peter Zijlstra <peterz@infradead.org>\nDate:   Fri Apr 25 17:39:01 2008 +0200\n\n    fix idle (arch, acpi and apm) and lockdep\n\n\nand git-x86 (generated via git-diff origin...git-x86) has:\n\ncommit 0a1679501624482a06c19af49d55b68d3973e2f0\nAuthor: Peter Zijlstra <peterz@infradead.org>\nDate:   Fri Apr 25 17:39:01 2008 +0200\n\n    fix idle (arch, acpi and apm) and lockdep\n    \n\nwhich I assume is the same patch as a different commit.\n\n\nThe old `doit':\n\ndoit()\n{\n\ttree=$1\n\tupstream=$2\n\n\tcd $GIT_TREE\n\tgit reset --hard \"$upstream\"\n\tgit fetch \"$tree\" || exit 1\n\tgit merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null\n\n\t{\n\t\tgit_header \"$tree\"\n\t\tgit log --no-merges ORIG_HEAD..FETCH_HEAD\n\t\tgit diff --patch-with-stat ORIG_HEAD\n\t} >$PULL/$tree.patch\n\t{\n\t\techo DESC\n\t\techo $tree.patch\n\t\techo EDESC\n\t\tgit_header \"$tree\"\n\t\tgit log --no-merges ORIG_HEAD..FETCH_HEAD\n\t} >$PULL/$tree.txt\n\tgit reset --hard \"$upstream\"\n}\n\nprevented that by doing a merge.\n\n\ngit-diff was \"wrong\" to claim that this change is actually present in the\norigin->git-x86 diff.  But I guess it cannot operate at that level and we\nneed to do the merge to resolve it.  Or something.\n\nho hum.\n"},{"id":"75468","messageId":"alpine.LFD.1.10.0804281437160.3119@woody.linux-foundation.org","threadId":"13298","inReplyTo":"20080428143501.7d6e3ad0.akpm@linux-foundation.org","subject":"Re: my git problem","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-04-28T21:47:17Z","receivedAt":"2008-04-28T21:47:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 28 Apr 2008, Andrew Morton wrote:\n> \n> origin.patch (generated via git-diff v2.6.25...origin) has:\n> \n> commit 7f424a8b08c26dc14ac5c17164014539ac9a5c65\n> Author: Peter Zijlstra <peterz@infradead.org>\n> Date:   Fri Apr 25 17:39:01 2008 +0200\n> \n>     fix idle (arch, acpi and apm) and lockdep\n> \n> \n> and git-x86 (generated via git-diff origin...git-x86) has:\n> \n> commit 0a1679501624482a06c19af49d55b68d3973e2f0\n> Author: Peter Zijlstra <peterz@infradead.org>\n> Date:   Fri Apr 25 17:39:01 2008 +0200\n> \n>     fix idle (arch, acpi and apm) and lockdep\n>     \n> \n> which I assume is the same patch as a different commit.\n\nYes. \n\nSo this is an example of the fact that that patch was merged in two \ndifferent trees as separate patches, so when you do\n\n\tgit diff origin..git-x86\n\nthen it shows literally the diff from the last common state, and does \n*not* take into account that since that last common state there has been \nupdates to the origin branch that essentially conflict (and in this case \ntrivially, by just duplicating the work).\n\n> The old `doit' prevented that by doing a merge.\n\nYes. And it sounds like what you want is that merge, followed by the diff. \nYou're not actually asking for \"what has changed since the last common \nstate\". You are literally asking for \"what would a merge result in\".\n\n> git-diff was \"wrong\" to claim that this change is actually present in the\n> origin->git-x86 diff.  But I guess it cannot operate at that level and we\n> need to do the merge to resolve it.  Or something.\n\nI don't actually see what was wrong with the old script.  The merge was\nreally oddly done, but apart from that, something like this should work\n(just your old script with some trivial fixes to 'git merge' and using\nsomewhat saner arguments):\n\n\tdoit()\n\t{\n\t\ttree=$1\n\t\tupstream=$2\n\t\n\t\tcd $GIT_TREE\n\t\tgit reset --hard \"$upstream\"\n\t\tgit fetch \"$tree\" || exit 1\n\t\tgit merge --no-commit FETCH_HEAD > /dev/null\n\t\n\t\t{\n\t\t\tgit_header \"$tree\"\n\t\t\tgit shortlog --no-merges ORIG_HEAD..FETCH_HEAD\n\t\t\tgit diff -p --stat ORIG_HEAD\n\t\t} >$PULL/$tree.patch\n\n\t\t{\n\t\t\techo DESC\n\t\t\techo $tree.patch\n\t\t\techo EDESC\n\t\t\tgit_header \"$tree\"\n\t\t\tgit log --no-merges ORIG_HEAD..FETCH_HEAD\n\t\t} >$PULL/$tree.txt\n\t\tgit reset --hard \"$upstream\"\n\t}\n\nbut obviously that will still result in problems if there are real conflicts.\n\n\t\t\tLinus\n"},{"id":"75470","messageId":"alpine.DEB.1.00.0804282302580.27457@eeepc-johanness","threadId":"13298","inReplyTo":"alpine.LFD.1.10.0804281437160.3119@woody.linux-foundation.org","subject":"Re: my git problem","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-28T22:04:37Z","receivedAt":"2008-04-28T22:04:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 28 Apr 2008, Linus Torvalds wrote:\n\n> On Mon, 28 Apr 2008, Andrew Morton wrote:\n> > \n> > origin.patch (generated via git-diff v2.6.25...origin) has:\n> > \n> > commit 7f424a8b08c26dc14ac5c17164014539ac9a5c65\n> > Author: Peter Zijlstra <peterz@infradead.org>\n> > Date:   Fri Apr 25 17:39:01 2008 +0200\n> > \n> >     fix idle (arch, acpi and apm) and lockdep\n> > \n> > \n> > and git-x86 (generated via git-diff origin...git-x86) has:\n> > \n> > commit 0a1679501624482a06c19af49d55b68d3973e2f0\n> > Author: Peter Zijlstra <peterz@infradead.org>\n> > Date:   Fri Apr 25 17:39:01 2008 +0200\n> > \n> >     fix idle (arch, acpi and apm) and lockdep\n> >     \n> > \n> > which I assume is the same patch as a different commit.\n> \n> Yes. \n\nFWIW that is why I suggested using --cherry-pick.  It tries to filter out \nthe patches from \"upstream\" by calculating a patch-id (Basically a SHA-1 \nof the patch), and leaving out all commits from \"downstream\" with the same \npatch-id.\n\nOf course, it does not always work perfectly, because it wants a context \nof 3 lines to agree.\n\nCiao,\nDscho\n"},{"id":"75472","messageId":"alpine.LFD.1.10.0804281512110.3119@woody.linux-foundation.org","threadId":"13298","inReplyTo":"alpine.LFD.1.10.0804281437160.3119@woody.linux-foundation.org","subject":"Re: my git problem","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-04-28T22:14:20Z","receivedAt":"2008-04-28T22:14:20Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 28 Apr 2008, Linus Torvalds wrote:\n> \n> I don't actually see what was wrong with the old script.  The merge was\n> really oddly done, but apart from that, something like this should work\n> (just your old script with some trivial fixes to 'git merge' and using\n> somewhat saner arguments):\n\nSide note: you are still going to have *exactly* the same issue if you \nhave other git trees (not origin) that contain the same patch. \n\nThe fact is, your model of \"merging by applying patches\" is the real \nproblem here. It's not a model that can work unless all trees are \nindependent and they obviously aren't. So trying to merge with \"origin\" is \nonly going to remove _one_ tree from the equation.\n\n\t\t\tLinus\n"},{"id":"75483","messageId":"20080428191413.6aa79054.akpm@linux-foundation.org","threadId":"13298","inReplyTo":"alpine.LFD.1.10.0804281512110.3119@woody.linux-foundation.org","subject":"Re: my git problem","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2008-04-29T02:14:13Z","receivedAt":"2008-04-29T02:14:13Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Mon, 28 Apr 2008 15:14:20 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:\n\n> \n> \n> On Mon, 28 Apr 2008, Linus Torvalds wrote:\n> > \n> > I don't actually see what was wrong with the old script.  The merge was\n> > really oddly done, but apart from that, something like this should work\n> > (just your old script with some trivial fixes to 'git merge' and using\n> > somewhat saner arguments):\n> \n> Side note: you are still going to have *exactly* the same issue if you \n> have other git trees (not origin) that contain the same patch. \n> \n\nyup.  The same-patch-in-two-trees problem is surprisingly rare.\n"},{"id":"75550","messageId":"20080429171519.GA21310@fieldses.org","threadId":"13298","inReplyTo":"alpine.LFD.1.10.0804281222190.3119@woody.linux-foundation.org","subject":"Re: my git problem","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2008-04-29T17:15:19Z","receivedAt":"2008-04-29T17:15:19Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Apr 28, 2008 at 12:28:38PM -0700, Linus Torvalds wrote:\n> \n> \n> On Mon, 28 Apr 2008, Johannes Schindelin wrote:\n> > \n> > On Mon, 28 Apr 2008, Andrew Morton wrote:\n> > > \n> > > That's missing the \"logical\" bit :)\n> > \n> > Heh, you're right.  I am too used to Git to think how other people would \n> > feel about these things... :-)\n> \n> No, you are both wrong.\n> \n> You're wrong because apparently you never did abstract algebra and set \n> theory in school.\n\nHmph.  I've got a PhD in algebra and still find that choice of operators\nconfusing.\n\n(Which may just be further evidence that one can take a lot of classes\nand still be an idiot.)\n\n> If you know math, git actually does the rigth and very much the *logical* \n> thing.\n> \n> So \"..\" is a simple difference, while \"...\" is a more complex difference. \n> \n> They mean different things for different operation types, but that is \n> again something a math person takes for granted (ie in algebra, a \"+\" or \n> \"-\" is just a random operation that follows certain rules: \"a-b\" means one \n> thing for the set of real numbers, and something *totally* different if \n> you are talking about set algebra).\n\nI suspect one reason the set-difference operator is more commonly\nwritten with a backslash than a minus sign is that set difference is\ndifferent enough from anything else usually called subtraction that most\npeople find it confusing to use the same notation.\n\nI can sorta buy the argument that \"A...B\" means most generally \"some\nkind of difference between the three sets A, A^B, and B\", and that in\nthe context of \"git diff\" it's most sensible to take ordering into\naccount and produce some approximation of a diff between A^B and B.  I'd\npersonally have found an entirely separate operator simpler to\nunderstand.  But perhaps there's only so many keys on the keyboard.\n\n--b.\n"},{"id":"75649","messageId":"m3prs7oixp.fsf@localhost.localdomain","threadId":"13298","inReplyTo":"20080429171519.GA21310@fieldses.org","subject":"Re: my git problem","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-04-30T08:17:50Z","receivedAt":"2008-04-30T08:17:50Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"J. Bruce Fields\" <bfields@fieldses.org> writes:\n\n> On Mon, Apr 28, 2008 at 12:28:38PM -0700, Linus Torvalds wrote:\n>> \n>> \n>> On Mon, 28 Apr 2008, Johannes Schindelin wrote:\n>>> \n>>> On Mon, 28 Apr 2008, Andrew Morton wrote:\n>>>> \n>>>> That's missing the \"logical\" bit :)\n>>> \n>>> Heh, you're right.  I am too used to Git to think how other people would \n>>> feel about these things... :-)\n>> \n>> No, you are both wrong.\n>> \n>> You're wrong because apparently you never did abstract algebra and set \n>> theory in school.\n[...]\n>> If you know math, git actually does the rigth and very much the *logical* \n>> thing.\n>> \n>> So \"..\" is a simple difference, while \"...\" is a more complex difference. \n>> \n>> They mean different things for different operation types, but that is \n>> again something a math person takes for granted (ie in algebra, a \"+\" or \n>> \"-\" is just a random operation that follows certain rules: \"a-b\" means one \n>> thing for the set of real numbers, and something *totally* different if \n>> you are talking about set algebra).\n[...]\n> I can sorta buy the argument that \"A...B\" means most generally \"some\n> kind of difference between the three sets A, A^B, and B\", and that in\n> the context of \"git diff\" it's most sensible to take ordering into\n> account and produce some approximation of a diff between A^B and B.  I'd\n> personally have found an entirely separate operator simpler to\n> understand.  But perhaps there's only so many keys on the keyboard.\n\nIMHO adding support for a..b and a...b to git-diff is a bit of trick,\nas a..b and a...b were created to represent a set of revisions (a\nrevision range).\n\nIf we have linear history:\n\n   *---*---*---a---*---*---b\n\nthen a..b notation for a revision range is very natural, and having\ngit-diff interprete \"a..b\" as \"a b\" (for git-diff only endpoints\nmatter) to allow copy'n'pasting between git-log and git-diff, and\nbetween git-fetch messages and git-diff was a good extension.\n\nNow if the history is not linear, as in example below:\n\n   *---*---*---x---*---*---b\n                \\\n                 \\-*---a\n\nthen \"a..b\", which is shortcut for \"b ^a\" (b --not a), returns x..b\nrange (set) of revisions.  If you read \"a..b\" as \"what's in 'b'\nsince 'a'\" it makes perfect sense.  But \"git diff a..b\" is still\n\"git diff a b\", not \"git diff x b\". \n\n\nIt would be perhaps as good notation to have \"git diff a..b\" mean\n\"git diff x b\", i.e. be diff between endpoints of \"git log a..b\",\nand have \"git diff a...b\" be \"git diff a b\", i.e. to be diff between\nendpoints^W points of \"git log a...b\"... but if there is no clean\nwinner, simplicity of implementation wins. \n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"75733","messageId":"871w4mwojn.wl%cworth@cworth.org","threadId":"13298","inReplyTo":"alpine.LFD.1.10.0804281200130.3119@woody.linux-foundation.org","subject":"Re: my git problem","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2008-05-01T06:01:32Z","receivedAt":"2008-05-01T06:01:32Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Mon, 28 Apr 2008 12:21:17 -0700 (PDT), Linus Torvalds wrote:\n> On Mon, 28 Apr 2008, Andrew Morton wrote:\n> > I'd have expected git-log to operate on the same patches as git-diff.\n>\n> No, not at all.\n>\n>  - \"git log\" shows each commit in a range.\n>\n>  - \"git diff\" shows just the difference between two states.\n>\n> The two have nothing in common. One operates on lots of individual commits\n> (git log) individually, while the other one fundamentally operates on just\n> two end-points (git diff).\n\nYes, the two operations are internally operating on different things,\n(exactly as described).\n\n> And \"a..b\" and \"a...b\" means two totally different things for the two\n> totally different operations.\n\nBut the internal difference doesn't justify the totally different\nmeaning of \"a..b\" and \"a...b\" for these two operations. And in the\nrest of your message you didn't justify the difference at all, (just\nthe fact that there *can* be a difference).\n\nAs a concrete example, I often want to view a series of patches that\nis unique to a branch. I can easily do that with:\n\n\tgit log -p a..b\n\nNow, if I want to view basically the same information, but in a\n\"combined\" view, (a single patch from the beginning to the final\nstate), I have to instead do:\n\n\tgit diff a...b\n\nAnd that's the part that's really confusing people, I think, (see\nAndrew Morton running into the problem here, and Havoc Pennington\nelsewhere). Conceptually, \"a..b\" is a way to say \"the commits that are\nunique to 'b' compared to 'a'\", and that works great for git-log. But\nwhen a similar concept is often desired for git-diff it's spelled\n\"a...b\" instead. What's the justification for that? (Other than\nhistorical accident.)\n\nMeanwhile, you could even point to a similar case with the opposite\nforms of each command. That is, one can see a series of patches with:\n\n\tgit log -p a...b\n\nAnd again, one can get get basically the same information in a\ncombined, single-patch form with:\n\n\tgit diff a..b\nor:\tgit diff b..a\n\ndepending on which direction one would like the combined version to be\nin. Again, why the opposite syntax for basically the same information?\n\nSo git-log and git-diff are consistent in not treating the \"..\" and\n\"...\" syntax uniformly, but I can't see any good justification for\nthat.\n\nI don't think this second case is causing much problem. The symmetric\ndifference that's described by \"git log a...b\" isn't something I end\nup needing very often, anyway. Meanwhile, a single patch between two\narbitrary states is extremely common, but I've always expressed that\nnaturally as \"git diff a b\", (by analogue with good old \"diff fileA\nfileB\"), and never felt a need to spell this command as \"git diff\na..b\".\n\nSo, I do think the handling of \"..\" and \"...\" in git-diff is\nobjectively backwards compared to the way that git-log, git-rev-list\nand everything else treat these operators.\n\nI don't know what can be done to fix this now, though. Just expect\nusers to get confused, and then try to get them to drill \"git log\na..b\" and \"git diff a...b\" into their wee little brains.\n\nOr maybe go Elijah's route and invent a new top-level command name in\nwhich issues like this can get fixed. (I've been lukewarm on the idea\nafter watching the cogito attempt eventually be abandoned. I'd really\nmuch rather see Elijah's ideas get pushed down into git itself for the\nmost part. But it's tough when backwards-compatibility prevents fixing\nsome things that are obviously confusing people.)\n\n-Carl\n"}]}