{"thread":{"id":"4122","subject":"git-bisect failed me again","startedAt":"2006-05-12T07:02:49Z","lastAt":"2006-05-12T16:11:19Z","messageCount":5,"participants":["Andrew Morton","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"19860","messageId":"20060512000249.71933599.akpm@osdl.org","threadId":"4122","inReplyTo":null,"subject":"git-bisect failed me again","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2006-05-12T07:02:49Z","receivedAt":"2006-05-12T07:02:49Z","isPatch":false,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"\nTrying to find a recently-merged box-killer in Len's tree:\n\nbix:/usr/src/git26> cat .git/branches/git-acpi \ngit+ssh://master.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git#test\n\ngit-checkout git-acpi\ngit-bisect reset\ngit-bisect start\ngit-bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e\ngit-bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9\n\nAnd it led me to\n\nbix:/usr/src/git26> git-bisect good\n9011bff4bdc0fef1f9a782d7415c306ee61826c9 is first bad commit\ndiff-tree 9011bff4bdc0fef1f9a782d7415c306ee61826c9 (from 7e1f19e50371e1d148226b64c8edc77fec47fa5b)\nAuthor: Len Brown <len.brown@intel.com>\nDate:   Thu May 11 00:28:12 2006 -0400\n\n    ACPI: delete newly added debugging macros in processor_perflib.c\n    \n\nwhich isn't a buggy patch.\n\nbix:/usr/src/git26> cat .git/BISECT_LOG\ngit-bisect start\n# good: [ff2fc3e9e3edb918b6c6b288485c6cb267bc865e] ACPI: EC acpi-ecdt-uid-hack\ngit-bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e\n# bad: [9011bff4bdc0fef1f9a782d7415c306ee61826c9] ACPI: delete newly added debugging macros in processor_perflib.c\ngit-bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9\n# good: [c52851b60cc0aaaf974ff0e49989fb698220447d] P-state software coordination for speedstep-centrino\ngit-bisect good c52851b60cc0aaaf974ff0e49989fb698220447d\n# good: [7e1f19e50371e1d148226b64c8edc77fec47fa5b] ACPI: UP build fix for bugzilla-5737\ngit-bisect good 7e1f19e50371e1d148226b64c8edc77fec47fa5b\n\n\nA had a second go - fed it the very first and last commit IDs in that tree.\n Same result.\n\nbix:/usr/src/git26> git-bisect good\n9011bff4bdc0fef1f9a782d7415c306ee61826c9 is first bad commit\ndiff-tree 9011bff4bdc0fef1f9a782d7415c306ee61826c9 (from 7e1f19e50371e1d148226b64c8edc77fec47fa5b)\nAuthor: Len Brown <len.brown@intel.com>\nDate:   Thu May 11 00:28:12 2006 -0400\n\n    ACPI: delete newly added debugging macros in processor_perflib.c\n    \n    Signed-off-by: Len Brown <len.brown@intel.com>\n\n:040000 040000 f7a3b4cfdb128fb6a777b2e30a83c63edd70f46a 2ca1c42aaae65df9052d60d274aaec3116e30c2d M      drivers\nbix:/usr/src/git26> cat .git/BISECT_LOG       \ngit-bisect start\n# good: [74951d613e758f9709d6f2173107be68f18f77f4] ACPI: Remove debugging macros from drivers/acpi/thermal.c\ngit-bisect good 74951d613e758f9709d6f2173107be68f18f77f4\n# bad: [9011bff4bdc0fef1f9a782d7415c306ee61826c9] ACPI: delete newly added debugging macros in processor_perflib.c\ngit-bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9\n# good: [c52851b60cc0aaaf974ff0e49989fb698220447d] P-state software coordination for speedstep-centrino\ngit-bisect good c52851b60cc0aaaf974ff0e49989fb698220447d\n# good: [7e1f19e50371e1d148226b64c8edc77fec47fa5b] ACPI: UP build fix for bugzilla-5737\ngit-bisect good 7e1f19e50371e1d148226b64c8edc77fec47fa5b\n\n\nWhat did I do wrong this time?\n\nThanks.\n"},{"id":"19861","messageId":"Pine.LNX.4.64.0605120738190.3866@g5.osdl.org","threadId":"4122","inReplyTo":"20060512000249.71933599.akpm@osdl.org","subject":"Re: git-bisect failed me again","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-12T14:55:44Z","receivedAt":"2006-05-12T14:55:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 12 May 2006, Andrew Morton wrote:\n> \n> Trying to find a recently-merged box-killer in Len's tree:\n> \n> bix:/usr/src/git26> cat .git/branches/git-acpi \n> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git#test\n> \n> git-checkout git-acpi\n\nJust for others: if you already have a Linux repo, this is the perfect \ntime to do\n\n\tgit clone --reference <old-linux-repo>\n\t\tgit://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6\n\nto get that linux-acpi-2.6 repository.\n\nAnd for Junio: good job on that \"--reference\" flag. I used to do a local \nclone and then force an update, this was much better.\n\n> git-bisect reset\n> git-bisect start\n> git-bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e\n> git-bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9\n> \n> And it led me to\n> \n> bix:/usr/src/git26> git-bisect good\n> 9011bff4bdc0fef1f9a782d7415c306ee61826c9 is first bad commit\n> \n> which isn't a buggy patch.\n\nWell, to see what's up, do \"git bisect visualize\". That tends to not only \nhelp bisect things (for when you want to pick a different bisection \npoint), it's also a wonderfully visual tool to what the f*%& happens when \nsomething goes wrong.\n\nAnyway, when I replay your log:\n\n> bix:/usr/src/git26> cat .git/BISECT_LOG\n> git-bisect start\n> # good: [ff2fc3e9e3edb918b6c6b288485c6cb267bc865e] ACPI: EC acpi-ecdt-uid-hack\n> git-bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e\n> # bad: [9011bff4bdc0fef1f9a782d7415c306ee61826c9] ACPI: delete newly added debugging macros in processor_perflib.c\n> git-bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9\n> # good: [c52851b60cc0aaaf974ff0e49989fb698220447d] P-state software coordination for speedstep-centrino\n> git-bisect good c52851b60cc0aaaf974ff0e49989fb698220447d\n> # good: [7e1f19e50371e1d148226b64c8edc77fec47fa5b] ACPI: UP build fix for bugzilla-5737\n> git-bisect good 7e1f19e50371e1d148226b64c8edc77fec47fa5b\n\nI definitely get the same \"9011bff4bdc0fef1f9a782d7415c306ee61826c9 is \nfirst bad commit\" result, and going along visually at every point makes it \nvery very obvious that git-bisect is right.\n\n(In fact, the _most_ visually obvious way to do it is to do this:\n\n\tgit bisect reset\n\tgit bisect start\n\tgit bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e\n\tgit bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9\n\tgit bisect visualize &\n\tgit bisect good c52851b60cc0aaaf974ff0e49989fb698220447d\n\t.. go into the \"file\" menu, and select \"re-read references\" ..\n\tgit-bisect good 7e1f19e50371e1d148226b64c8edc77fec47fa5b\n\t.. do \"re-read references\" again ..\n\nand you'll see exactly what \"git bisect\" is doing).\n\nYou claimed that the previous commit (7e1f19..) was good, and that \n9011bff.. itself was bad). So if that was true, then it really _was_ that \n9011bff.. commit that caused it.\n\n> What did I do wrong this time?\n\nYou did nothing wrong, unless your _testing_ was wrong, and one of your \n\"git bisect good\" entries should have been bad, or the other way around \n(you booted into the wrong kernel, so you thought something was ok when it \nwasn't).\n\nWhy are you so sure that git bisect gave the wrong answer? This is ACPI, \nafter all. For all we know, subtle cache-effects could break it.\n\n\"git bisect\" sadly won't help with bugs that show up due to some other \nsubtle interaction..\n\nAnyway, my first guess would be that you might have marked something good \nor bad that wasn't. How sure are you about that initial \"git bisect bad\" \nyou did?\n\n\t\tLinus\n"},{"id":"19862","messageId":"20060512081207.6cd701f9.akpm@osdl.org","threadId":"4122","inReplyTo":"Pine.LNX.4.64.0605120738190.3866@g5.osdl.org","subject":"Re: git-bisect failed me again","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2006-05-12T15:12:07Z","receivedAt":"2006-05-12T15:12:07Z","isPatch":false,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"Linus Torvalds <torvalds@osdl.org> wrote:\n>\n> (In fact, the _most_ visually obvious way to do it is to do this:\n> \n>  \tgit bisect reset\n>  \tgit bisect start\n>  \tgit bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e\n>  \tgit bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9\n>  \tgit bisect visualize &\n>  \tgit bisect good c52851b60cc0aaaf974ff0e49989fb698220447d\n>  \t.. go into the \"file\" menu, and select \"re-read references\" ..\n>  \tgit-bisect good 7e1f19e50371e1d148226b64c8edc77fec47fa5b\n>  \t.. do \"re-read references\" again ..\n> \n>  and you'll see exactly what \"git bisect\" is doing).\n> \n>  You claimed that the previous commit (7e1f19..) was good, and that \n>  9011bff.. itself was bad). So if that was true, then it really _was_ that \n>  9011bff.. commit that caused it.\n> \n>  > What did I do wrong this time?\n> \n>  You did nothing wrong, unless your _testing_ was wrong, and one of your \n>  \"git bisect good\" entries should have been bad, or the other way around \n>  (you booted into the wrong kernel, so you thought something was ok when it \n>  wasn't).\n> \n>  Why are you so sure that git bisect gave the wrong answer? This is ACPI, \n>  after all. For all we know, subtle cache-effects could break it.\n> \n>  \"git bisect\" sadly won't help with bugs that show up due to some other \n>  subtle interaction..\n> \n>  Anyway, my first guess would be that you might have marked something good \n>  or bad that wasn't. How sure are you about that initial \"git bisect bad\" \n>  you did?\n\nAm pretty confident.\n\n\nbix:/usr/src/25> grep '^commit ' patches/git-acpi.patch \ncommit 9011bff4bdc0fef1f9a782d7415c306ee61826c9\t\t<- This was my `bad'\ncommit 5d882e684aafea30c508d86d235327d94e1d38ae\ncommit 14394600cdfe0c952ce662a32a68c5c5524d32ac\ncommit da95181baf3cf6a2bd81c0c8af1d4c6790703e4f\ncommit b128440ed11d108c375772b7fe9ad46d2ac07084\t\t<- This was the bug\ncommit 61ce94e1f8b16b1694475adba9bf2e07fac02020\ncommit a48142ea89e02ed0aba0a481ead1e9302e1a4160\ncommit d5c11d3ba31d6ead24f27de648dc2dcfde5092e3\ncommit f6a08bf2cb06ee3d5be749cf20685b677619bc8e\ncommit 2cb7f1704275905b7548eee299c554bcdc5cf357\ncommit 2ce2b16467f0d43d0f8933eb4821b2369b31888c\ncommit 8ec0cbd9386a40a3afffad78334f4403b256dc4b\ncommit ba8acc597cff47fcbbd7b9f0d73a59e784852d8b\ncommit 7e9e8344848d80c9b6e1b9eaf32dd498b48ca5bb\ncommit d2606159ffdf8e435f6a7714f8e8910672b944d5\ncommit 8fb1d47b74e2bad912f74783048b433a1e313799\ncommit f7c0fce6da5cb68b8b0e203df4ff8ef9b3265105\ncommit 61e295946a248e43cf244cb24097e284d1d00e35\ncommit a32283362a7a8e7cff608fe25299a59925daea4d\ncommit 4cd5611ca16348b3805ddcf89b97fe670e76faaa\ncommit 529758bad4b0f9a8eec56fcc5cad342e9680ea36\ncommit 91afb9e683426ff238aab159e60f6d6e792e7488\ncommit 9f102deee398ea4dfcee3b2108dc00bc59ea877b\ncommit e85eb9a47f19a26b636b58106e309f8db6b2415d\ncommit 4597ac50598b85a09417df531849b80ce2e8e44b\ncommit 74951d613e758f9709d6f2173107be68f18f77f4\ncommit e6f1f3c54974a30c65ea0b699809d12f0aa04272\ncommit c12ea918ee175ceb3a258cd81f1c43e897d0c0bc\ncommit eefa27a93a0490902f33837ac86dbcf344b3aa29\ncommit ff2fc3e9e3edb918b6c6b288485c6cb267bc865e\ncommit df42baa0d8e54df18dd9366dd7c93d6be7d5d063\ncommit 200739c179c63d21804e9e8e2ced265243831579\ncommit 5e15b92d07fb11490c886c5dd7567f523ea43e2d\ncommit 9224a867c497053842dc595e594ca6d32112221f\ncommit 459c7266d7a5c1730169258217e25fdd1b7ca854\ncommit 1a36561607abf1405b56a41aac2fd163429cd1f8\ncommit e4513a57ef719d3d6d1cee0ca4d9f4016aa452bb\ncommit 578b333bfe8eb1360207a08a53c321822a8f40f3\ncommit 9d9f749b316ac21cb59ad3e595cbce469b409e1a\ncommit cd090eedd85256829f762677d0752a846c1b88b9\ncommit 81507ea9cfa64e9851b53e0fefebfa776eda9ecb\ncommit 1c6e7d0aeecac38e66b1bb63e3eff07b2a1c2f2c\ncommit b5f2490b6e3317059e87ba40d4f659d1c30afc1f\ncommit 1acfb7f2b0d460ee86bdb25ad0679070ec8a5f0d\ncommit 7e1f19e50371e1d148226b64c8edc77fec47fa5b\ncommit 1300124f69cafc54331bc06e968a8dd67863f989\ncommit ec7381d6bfd3e7b8d2880dd5e9d03b131b0603f6\ncommit 8313524a0d466f451a62709aaedf988d8257b21c\ncommit ea936b78f46cbe089a4ac363e1682dee7d427096\ncommit 52fc0b026e99b5d5d585095148d997d5634bbc25\ncommit 46358614ed5b031797522f1020e989c959a8d8a6\ncommit 6665bda76461308868bd1e52caf627f4cb29ed32\ncommit fdc136ccd3332938e989439c025c363f8479f3e6\ncommit a1f9e65e2085e0a87f28a4d5a8ae43b32c087f24\ncommit 1fee94034917aa711fcbd4ebf4c36f7ebd9fa7d6\ncommit 0eacee585a89ce5827b572a73a024931506bef48\ncommit 9cfda2c94df61c9f859b474abe774c65a4464d0a\ncommit d52bb94d56676acd9bdac8e097257a87b4b1b2e1\ncommit c52851b60cc0aaaf974ff0e49989fb698220447d\ncommit 09b4d1ee881c8593bfad2a42f838d85070365c3e\ncommit 3b2d99429e3386b6e2ac949fc72486509c8bbe36\ncommit ffd642e748c867a7339b57225b8bf8b9a0dcd9c5      <- This was my `good'\ncommit f9ea7fd8be9827791f407ca1191ff70ec25eb2d9\ncommit b60e49b2383db0334bef1f0d9cdad9bec2336050\ncommit 1ca218d3bd6acca0922a349cb76e3244d27ebfba\n\nand git-bisect claimed that 9011bff4bdc0fef1f9a782d7415c306ee61826c9\nintroduced the bug.  \n"},{"id":"19863","messageId":"Pine.LNX.4.64.0605120823170.3866@g5.osdl.org","threadId":"4122","inReplyTo":"20060512081207.6cd701f9.akpm@osdl.org","subject":"Re: git-bisect failed me again","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-12T15:45:20Z","receivedAt":"2006-05-12T15:45:20Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 12 May 2006, Andrew Morton wrote:\n>\n> Linus Torvalds <torvalds@osdl.org> wrote:\n> > \n> >  Anyway, my first guess would be that you might have marked something good \n> >  or bad that wasn't. How sure are you about that initial \"git bisect bad\" \n> >  you did?\n> \n> Am pretty confident.\n\nAnd I'm pretty damn sure it ain't.\n\nAndrew, git is _not_ linear. You can't just list the commits, take the \nlast and the first, and say \"the last must be bad, the first must be \ngood\". Which seems to be what you did.\n\n> \n> \n> bix:/usr/src/25> grep '^commit ' patches/git-acpi.patch \n> commit 9011bff4bdc0fef1f9a782d7415c306ee61826c9\t\t<- This was my `bad'\n> commit 5d882e684aafea30c508d86d235327d94e1d38ae\n> commit 14394600cdfe0c952ce662a32a68c5c5524d32ac\n> commit da95181baf3cf6a2bd81c0c8af1d4c6790703e4f\n> commit b128440ed11d108c375772b7fe9ad46d2ac07084\t\t<- This was the bug\n\nThat \"b128440e..\" commit wasn't even among the collection of commits that \nyou tested with \"git bisect\" in the first place. \n\nYou've apparently created a \"list of commits\" that doesn't include any \nmerges, and then you decided that the \"most recent of those commits was \nobviously bad\".\n\nWHICH IS NOT TRUE.\n\nYou never actually even TESTED that 9011bff commit, did you? In fact, I'm \n100% sure you didn't. You just said \"it's bad\", without any confidence \nwhat-so-ever except that it happened to be first on your list.\n\nRight?\n\nThe fact is, it seems that the way you generated the list of commits was \nbasically:\n\n - pick every commit that is not a merge and doesn't exist in linus tree.\n\n   (ie you basically did the equivalent of \"git-rev-list --no-merges \n   linus..acpi\", although it's possible that you used \"git whatchanged\" or \n   something else that will not show merges because they don't generate \n   diffs)\n\nAnd then you believed that you had a linear series of commits, and that \nthe most recent commit must thus be the buggy one.\n\nBut git isn't linear. Never has been. The fact that commits get (roughtly) \nsorted by date (modified by their ancestry relationships either subtly or \ngrossly depending on whether --topo-sort is off or on) does not make \nanything linear.\n\nThe commit you mark as \"this was the bug\" is on a totally different \ndevelopment branch from the one you marked \"bad\". That development branch \nwas merged with the branch that your \"bad\" commit came from with commit \n7378614.. (which is not on your list at all):\n\n\t\"Pull bugzilla-5737 into test branch\"\n\nbut there are actually a few other merges there too (and ACPI-only commits \nthat aren't reachable from your \"top\" bad commit).\n\n> and git-bisect claimed that 9011bff4bdc0fef1f9a782d7415c306ee61826c9\n> introduced the bug.  \n\nHell no. Git bisect did no such thing at all. YOU DID.\n\nGo back and look at what your sequence of instructions was (from your \noriginal email):\n\n ->> Trying to find a recently-merged box-killer in Len's tree:\n ->> \n ->> bix:/usr/src/git26> cat .git/branches/git-acpi \n ->> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git#test\n ->> \n ->> git-checkout git-acpi\n ->> git-bisect reset\n ->> git-bisect start\n ->> git-bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e\n ->> git-bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9\n ->> \n ->> And it led me to\n\nand notice how YOU claimed that \"9011bff4..\" was bad at the very\nbeginning of the \"git bisect\" run.  Not \"git bisect\". YOU. You started off \nby claiming that 9011bff4 was bad, apparently without having ever even \ntested it.\n\nThe way \"git bisect\" works is that if you give it garbage information, it \n_will_ give you a garbage result. That's pretty much guaranteed. But if \nyou actually give it tested and correct information, it will very \nefficiently zero in on what the problem really was.\n\nAnd the whole _point_ about \"git bisect\" is that the git history isn't \nlinear. If it was linear, you wouldn't need a tool to bisect it at all: \nyou'd just pick the middle entry from the history list, and use it. It \nwould be so trivial to bisect by hand, that using a tool is just \nunnecessary.\n\nSo really, take a look at \"git bisect visualize\". In this case, you should \nhave noticed that you had a list of 50+ commits, but when you did\n\n\tgit bisect good ff2fc3e\n\tgit bisect bad 9011bff\n\tgit bisect visualize\n\nyou had cut your list of commits down to just six (none of which was the \nbug).\n\nThis is why I integrated \"gitk\" immediately when it became available. It's \nreally important to see the non-linear history, because if you don't \nvisualize it (either mentally or with a tool like \"gitk\"), you'll never \nunderstand what is going on. \n\n\t\tLinus\n"},{"id":"19864","messageId":"Pine.LNX.4.64.0605120852590.3866@g5.osdl.org","threadId":"4122","inReplyTo":"Pine.LNX.4.64.0605120823170.3866@g5.osdl.org","subject":"Re: git-bisect failed me again","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-12T16:11:19Z","receivedAt":"2006-05-12T16:11:19Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 12 May 2006, Linus Torvalds wrote:\n> \n> But git isn't linear. Never has been. The fact that commits get (roughtly) \n> sorted by date (modified by their ancestry relationships either subtly or \n> grossly depending on whether --topo-sort is off or on) does not make \n> anything linear.\n\nNote that totally independently of sort order (whether \"topo-order\" or the \nnormal cheaper \"order by date, but at least one chain of parenthood always \nfirst\"), you _will_ get the situation that a commit that was shown \"last\" \nin a linear list is actually merged long before.\n\nThe simplest case is this:\n\n\t\tmerge\n\t\t |  \\\n\t\t A   \\\n\t\t |    \\\n\t\t B     \\\n\t\t |      X\n\t\t C      |\n\t\t |\tY\n\t\t D\t|\n\t\t |      Z\n\t\t..\t..\n\nwhere the \"main branch\" is the A-B-C-D.. line of history, and the merge \nbrings in another \"X-Y-Z\" line of history.\n\nNow, the A-B-C branch may have gotten a lot more recent love and \nattention, and when you linearize it, since the normal ordering tends to \nshow it in a date-like order, you may get a list of commits like\n\n\t\tmerge\n\t\tA\n\t\tB\n\t\tC\n\t\tD\n\t\t..\n\t\tX\n\t\tY\n\t\tZ\n\t\t..\n\n\nwhich makes you think that \"A\" is much more recent than \"X\". That may be \nactually be _true_, but:\n\n - 'X' actually _showed_up_ in the mainline much later than A. So, if you \n   track another persons tree like this, X as a commit may be 2 weeks old, \n   but it might not have been in the tree you tracked yesterday, because \n   it hadn't been _merged_ until today.\n\n   So in a very real sense, from your standpoint, 'X' may be the 'recent' \n   one, because you hadn't seen it before, but you _had_ seen 'A' \n   yesterday.\n\n - Equally importantly, 'A' very much is _not_ a descendant of 'X' (ie, \n   'X' is _not_ reachable from 'A'). So even though 'A' is in a time-sense \n   much more recent than 'X', you can't say \"it's the most recent commit, \n   so if there's a bug in any of the series, the bug must have been \n   visible at point 'A'\".\n\nThis is why it's wrong to look at _any_ linearized list of commits and \nimply any ordering what-so-ever. There simply is no list ordering that \nguarantees anything at all, because even with \"topo-sort\", the only thing \nwe guarantee is that commits that are directly related to each other will \nalways sort the child before its parents. So even there, you can't \nactually say that one commit \"dominates\" another commit unless you end up \nlooking at the parenthood chain (and merges are really important).\n\n[ Strictly speaking, there is exactly _one_ thing you can say from just \n  seeing a list of commits: _if_ that list includes all types of commits \n  (ie notably merges and empty changes) _and_ if that list was generated \n  with just one \"top\" commit, then the first commit on the list will \n  dominate all other commits. But that's literally the only real ordering \n  you can ever know from just a list.\n\n  So looking at the first commit in a list is actually valid, but only if \n  you included all the merges and only if the list was generated by a git \n  command, and not sorted by any other criteria ]\n\n\t\t\tLinus\n"}]}