{"thread":{"id":"12611","subject":"git history order strange","startedAt":"2008-03-10T02:17:26Z","lastAt":"2008-03-10T05:18:52Z","messageCount":2,"participants":["Jan Engelhardt","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"71547","messageId":"Pine.LNX.4.64.0803100306420.21961@fbirervta.pbzchgretzou.qr","threadId":"12611","inReplyTo":null,"subject":"git history order strange","fromName":"Jan Engelhardt","fromEmail":"jengelh@computergmbh.de","sentAt":"2008-03-10T02:17:26Z","receivedAt":"2008-03-10T02:17:26Z","isPatch":false,"sender":{"key":"jengelh@computergmbh.de","avatar":null},"body":"Hi,\n\n\n\nI have noticed that git-rev-list can output commit IDs in the wrong \norder. Steps to reproduce:\n\n\tgit-clone git://git.kernel.org/pub/scm/git/git.git\n\tgit-rev-list 3bddd7d\n\nthis will output\n\n\t...lots of IDs...\n\t8e1454b5ad285ec5dd25758e799c589045aff9d4\n\t6b7d25d97bdb8a26719f90d17ff5c9720be68762\n\t...lots of more IDs...\n\nbut this order seems to be the wrong way around, as 8e14 is the parent \nof 6b7d:\n\n\tgit-log --pretty=raw 6b7d25d\n\tcommit 6b7d25d97bdb8a26719f90d17ff5c9720be68762\n\ttree 661dce6a7e0f319fa1c53eb94c34585ee52190e4\n\tparent 8e1454b5ad285ec5dd25758e799c589045aff9d4\n\nTo be noted that it only happens with `git-rev-list`, but not with \n`git-rev-list --date-order` or `git-rev-list --topo-order`.\nIs it a bug in git-rev-list w/o arguments, or do I have to expect\ncommits in random reverse order?\n\n\nthanks,\nJan\n"},{"id":"71551","messageId":"alpine.LFD.1.00.0803092208330.5896@woody.linux-foundation.org","threadId":"12611","inReplyTo":"Pine.LNX.4.64.0803100306420.21961@fbirervta.pbzchgretzou.qr","subject":"Re: git history order strange","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-03-10T05:18:52Z","receivedAt":"2008-03-10T05:18:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 10 Mar 2008, Jan Engelhardt wrote:\n> \n> To be noted that it only happens with `git-rev-list`, but not with \n> `git-rev-list --date-order` or `git-rev-list --topo-order`.\n> Is it a bug in git-rev-list w/o arguments, or do I have to expect\n> commits in random reverse order?\n\nThey are not in \"random\" order, but if you have some use that requires \nstrict topological order, then you do need --topo-order (or --date-order, \nwhich is just a specific case of --topo-order).\n\nBy \"strict\" topo order I mean that _all_ commits are properly sorted with \n_all_ children coming before their parents.\n\nThe regular \"unordered\" rev-list output does mean that at least _one_ \nchild will have been printed out before its parent, but if a commit has \nmultiple children, it's possible that it has been reached and printed \nthrough one of those children before all the other children have been \nparsed and output.\n\nPut another way: say that the tree looks like\n\n\t\t\t\t\tHEAD\n\t\t\t\t      /\n\t--- f --- e --- c --- b --- a\n\t            \\       /\n\t              - d -\n\nwhere 'a' is the most recent head commit. In this case, git-rev-list with \n--topo-sort would guarantee that *both* 'c' and 'd' will be printed before \n'e', but without --topo-sort, it only guarantees that it will print _one_ \nway of reaching 'e', but not necessarily all ways.\n\nIOW, you might see the sequence a, b, c, e, f, d (where 'd' is printed \nafter not only its direct parent, but even after its grandparent), but if \nyou gave 'a' as a starting point you would never see the sequence a, b, e, \nc, d, f (because there is no way to get to 'e' without going through \neither c or d).\n\nOf course, if you give both 'a' and 'e' to git-rev-list as starting \npoints, all bets are off (it doesn't have to go through 'c' or 'd' to get \nto 'e' in that case ;)\n\nSo there are _some_ ordering guarantees even without --topo-order or \n--date-order, but they are just much much weaker.\n\n\t\t\tLinus\n"}]}