{"thread":{"id":"1443","subject":"git-format-patch-script bug?","startedAt":"2005-08-07T07:35:29Z","lastAt":"2005-08-07T19:55:50Z","messageCount":4,"participants":["Eric W. Biederman","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"6899","messageId":"m1d5oqxkqm.fsf@ebiederm.dsl.xmission.com","threadId":"1443","inReplyTo":null,"subject":"git-format-patch-script bug?","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-08-07T07:35:29Z","receivedAt":"2005-08-07T07:35:29Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"\nI haven't had a chance to investigate this much\nyet but I have ran into a peculiar problem.\n\nI was trying to help someone track down a bug that\noccurred between linux-2.6.12 and linux-2.6.13-rc1.\nSince it was very much an unknown where the problem\nwas introduced I decided to run git format-patch\nso I could see what all of the differences were.\nThen to be certain the patch series worked I started\napplying them in order.  \n\nI didn't get very far when I had a patch conflict.\n\nLooking deeper git-diff-tree is always making the diffs\nagainst the parent instead of against the next commit\nin the series.  Which is largely sane.  However it does\nnot warn or fail when the parents and the next commit are different,\nwhich seems nonintuitive.\n\nEric\n"},{"id":"6906","messageId":"7vhde1y85y.fsf@assigned-by-dhcp.cox.net","threadId":"1443","inReplyTo":"m1d5oqxkqm.fsf@ebiederm.dsl.xmission.com","subject":"Re: git-format-patch-script bug?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-07T17:21:45Z","receivedAt":"2005-08-07T17:21:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"ebiederm@xmission.com (Eric W. Biederman) writes:\n\n> I was trying to help someone track down a bug that\n> occurred between linux-2.6.12 and linux-2.6.13-rc1.\n> Since it was very much an unknown where the problem\n> was introduced I decided to run git format-patch\n> so I could see what all of the differences were.\n> Then to be certain the patch series worked I started\n> applying them in order.  \n\nSorry, I offhand do not have a good re-design of what\nformat-patch should do for this purpose; the current design does\nnot try to deal with anything but a linear sequence of commits,\nprimarily because the command was done for preparing individual\ndeveloper's patch submission.\n\nI find your trying to find where the problem was introduced by\nreading every single change very laudable.  However, for the\npurpose of \"this one was good but somewhere before this one the\nthings got broken, where is it?\", I suspect that bisect would be\na better fit.\n\nThe way to use bisect is very simple.  First you make sure you\ndo not have unrecorded changes in your working tree, because\nbisect procedure would check out sequences of commits for you to\ntest there.  Then, you give it two \"known to be good\" and \"known\nto be bad\" commits.  The order you give them does not matter,\nbut \"good\" one _must_ be ancestor of \"bad\" one (the code\ncurrently does not check this):\n\n    $ git bisect start\n    $ git bisect good v2.6.12\n    $ git bisect bad  v2.6.13-rc1\n    Bisecting: 1035 revisions left to test after this\n\nAs soon as ou give these two pair, bisect starts thinking, and\nchecks out one revision that is roughly in the halfway between\nthese two good and bad commits.  You can, if you feel like, see\nwhich one is the first one it wants you to test, like this:\n\n    $ git log --max-count=1 --pretty=short bisect\n    commit 15d20bfd606c4b4454aeaa05fc86f77994e48c92\n    Author: Domen Puncer <domen@coderock.org>\n\n        [PATCH] ptrace_h8300: condition bugfix\n\nAt this point, your working tree has this commit checked out.\nCompile and test to see if this one is good or bad.  If it is\ngood, then you say \"good\":\n\n    $ git bisect good\n    Bisecting: 517 revisions left to test after this\n\nBisect eliminated about half commits from the original 1000+\nsuspects to be innocent, and checked out which one it wants you\nto check next.  Compile and test to see if this one is good or\nbad.  If it turns out to be bad, then you say \"bad\":\n\n    $ git bisect bad\n    Bisecting: 266 revisions left to test after this\n\nYou go on eliminating about half every time you run one test,\nand eventually it would find one commit that you may want to\nexamine more deeply by code inspection.\n"},{"id":"6907","messageId":"m1y87dwpak.fsf@ebiederm.dsl.xmission.com","threadId":"1443","inReplyTo":"7vhde1y85y.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-format-patch-script bug?","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-08-07T18:54:43Z","receivedAt":"2005-08-07T18:54:43Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> ebiederm@xmission.com (Eric W. Biederman) writes:\n>\n>> I was trying to help someone track down a bug that\n>> occurred between linux-2.6.12 and linux-2.6.13-rc1.\n>> Since it was very much an unknown where the problem\n>> was introduced I decided to run git format-patch\n>> so I could see what all of the differences were.\n>> Then to be certain the patch series worked I started\n>> applying them in order.  \n>\n> Sorry, I offhand do not have a good re-design of what\n> format-patch should do for this purpose; the current design does\n> not try to deal with anything but a linear sequence of commits,\n> primarily because the command was done for preparing individual\n> developer's patch submission.\n\nWhat format-patch does is currently is fine.  If format-patch would\nsimply notice the case and fail gracefully that would be sufficient to\navoid giving false impressions.\n\nDepending on the quality of the list from git-rev-list --merge-order\nI should even be able to achieve what I was attempting, by\nrunning git-diff-tree with an ordered list of revisions and \ntwo parents on the tree.\n\nEssentially I was attempting an export to quilt operation, which\nimplies a linearization of the changes.  As I recall a linearization\nof the changes is what BK export to CVS was built on.  So that\ncase may be worth returning to as there are a lot of interesting\ncases out there for it.\n\nThe other interest tid bit about my experiment was that\ngit-format-patch-script on 2000 diffs was sluggish, certainly slower\nthat the time to perform the write operations.  Why it was slow\nI don't know but it may be worth looking into.\n\n> I find your trying to find where the problem was introduced by\n> reading every single change very laudable.  However, for the\n> purpose of \"this one was good but somewhere before this one the\n> things got broken, where is it?\", I suspect that bisect would be\n> a better fit.\n\nIf you can teach the user how to use bisect, and git.  \n\nIf we could get gitweb to perform the bisect it would be helpful,\nor possibly when git settles down and everyone can be counted on\nto have git on their machine already, bisect would be a help.\n\nHad I been thinking a little more clearly I would have suggested\nwalking through the daily git snapshots as those are at least\nfairly big steps.\n\nFor the moment I think the unexpected behavior I found in git \nis more interesting then the problem I was actually trying to solve.\n\nEric\n"},{"id":"6909","messageId":"7viryhv7w9.fsf@assigned-by-dhcp.cox.net","threadId":"1443","inReplyTo":"m1y87dwpak.fsf@ebiederm.dsl.xmission.com","subject":"Re: git-format-patch-script bug?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-07T19:55:50Z","receivedAt":"2005-08-07T19:55:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"ebiederm@xmission.com (Eric W. Biederman) writes:\n\n> What format-patch does is currently is fine.  If format-patch would\n> simply notice the case and fail gracefully that would be sufficient to\n> avoid giving false impressions.\n\nHmph.  Since it uses merge-order, We should be able to change it\nuse the tagged output format of rev-list to detect the revision\nlist discontinuity and skip generating diff for such.  Or as you\nsuggest just run \"diff-tree with the first parent\".\n\nI've been wanting to update format-patch to take the commit\nbegin-end pair in the rev-parse format, that is:\n\n    $ git format-patch his..mine\n\nI am reluctant to actually do this right away, because this is\nan incompatible change from the current format:\n\n    $ git format-patch his mine\n\nThe same goes for rebase (and therefore cherry).  I could use an\nugly heuristics for backward compatibility like \"if invoked with\nexactly two parameters, and there is no prefix ^ nor .. in these\ntwo, then use the old interpretation, otherwise give them to\nrev-parse\", but I think this is ugly.\n\nSo my question to the list is: do people mind this change?\n"}]}