{"thread":{"id":"24052","subject":"RFC: Make git bisect submodule aware.","startedAt":"2010-06-09T12:50:29Z","lastAt":"2010-06-09T14:57:21Z","messageCount":2,"participants":["Steven Michalske","Johan Herland"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"143329","messageId":"6AC4E373-C28F-455E-93A6-6FA5A57723A2@gmail.com","threadId":"24052","inReplyTo":null,"subject":"RFC: Make git bisect submodule aware.","fromName":"Steven Michalske","fromEmail":"smichalske@gmail.com","sentAt":"2010-06-09T12:50:29Z","receivedAt":"2010-06-09T12:50:29Z","isPatch":false,"sender":{"key":"smichalske@gmail.com","avatar":"https://gravatar.com/avatar/721f27456adc9ac84f3bb235f021a70015abb9e09222ae8622fc5579c6a203c1?d=mp&s=160"},"body":"When git bisect discovers that the change set that creates the failure  \nalso contains a submodule change, that submodule should then be  \nbisected starting with the good super modules code and working to a  \nbreak in the sub module.  If the change contains submodule change and  \nsuper code changes than the bisection gets trickier, so we need some  \nideas on how to solve that search.\n\nExample:\n\nSuper: A-B-C-D-E\nSub:   s-s-y-y-z\n\nWhere s is not required to be a parent of y,  meaning that there might  \nbe 300 commits or just 1 between s and y in the submodule or they are  \ndisjoint then the bisecting should happen both routes into the  \nsubmodule.\n\nSo the git bisect found that the offending commit is C\n\nNow if the offending commit only changes 1 submodule than it is a  \nnormal bisect for the changed submodule.\n\nIf in commit C file foo.c changed and the submodule changed a bit more  \nwork is needed.\n\nIf foo.c is not dependent on a new feature from between s and y than  \nwe are good, otherwise I feel a bit of human intervention might be  \nneeded for marking a 'good' version in the submodule.  Otherwise we  \nhave to search for a 'good' starting point, a binary bisection  \nprobably won't help much but probably would not hurt, since you need a  \n'good' commit to start the bisection from.\n\nSo for the not dependent on new feature/bugfix in the submodule.\n\nB's foo.c and s -> good/bad?\nB's foo.c and y -> good/bad?\nC's foo.c and s -> good/bad?\nC's foo.c and y -> good/bad?\n\nhave fun bisecting.....\n\nIt might be good to interactively ask, for this bisection will file  \nfoo.c have an affect?\nIf the file has an effect:\nAsk if C's foo.c will work with range s..y, if not what is the  \nexpected range for operation, we know that we need version u of  \nsubmodule to compile C's foo.c. Or we have to search (linear from s)  \nto where we can work.\notherwise, just bisect the submodule.\n\nSteve\n"},{"id":"143344","messageId":"201006091657.21735.johan@herland.net","threadId":"24052","inReplyTo":"6AC4E373-C28F-455E-93A6-6FA5A57723A2@gmail.com","subject":"Re: RFC: Make git bisect submodule aware.","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2010-06-09T14:57:21Z","receivedAt":"2010-06-09T14:57:21Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 09 June 2010, Steven Michalske wrote:\n> When git bisect discovers that the change set that creates the\n> failure also contains a submodule change, that submodule should then\n> be bisected starting with the good super modules code and working to\n> a break in the sub module.  If the change contains submodule change\n> and super code changes than the bisection gets trickier, so we need\n> some ideas on how to solve that search.\n>\n> Example:\n>\n> Super: A-B-C-D-E\n> Sub:   s-s-y-y-z\n>\n> Where s is not required to be a parent of y,  meaning that there\n> might be 300 commits or just 1 between s and y in the submodule or\n> they are disjoint then the bisecting should happen both routes into\n> the submodule.\n>\n> [...]\n\nMy general feeling about this scenario is that 'git bisect' should not \nautomatically descend into submodules and continue bisecting there.\n\nAs you observe, there may be weird co-dependencies between the \nsuperproject and the submodule (or even between different submodules), \nso the safest default in this situation is for 'git bisect' to simply \nbail out.\n\nThen the user can at his/her leisure figure out if the best way to \nproceed is indeed a nested 'git bisect' in the submodule, and if so, \nwhich is the most appropriate version of the superproject (or other \nsubmodules) to use for this nested bisect.\n\nTrying to make Git too \"clever\" about these things is likely to come \nback and bite us in the ass.\n\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"}]}