Grant Likely wrote: 
On 6/28/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
  
    The bsp I am working on works with 2.6.16.21 but fails with 2.6.17.

    How can I find the individual patches that make up the transition
from 2.6.16.21 to 2.6.17 ?
    

Unfortunately, there isn't a direct line between .16.21 and .17 which
makes it complicated.  Does your bsp work with .16?  If so; you can
use the 'git bisect' command to figure out exactly where the
regression occured.

If it doesn't work on .16; you can do a bisect between .16 and .16.21
to figure out what patch is missing between .16 and .17.

$ git bisect good v2.6.16
$ git bisect bad           # the head of the tree
compile, test, etc.
$ git bisect good|bad    # depends on whether it works or not
compile, test, etc
$ git bisect good|bad    # you get the idea... repeat until it's narrowed down
$ git log                          # see where you are in the git tree.
    Thank You git bisect has proven to be incredibly interesting.

    One question/problem - maybe an incomplete understanding of git.
   
    What I need to do is get to some version of 2.6.16 - as they all work for me.

    cut in my patches.

    And THEN start bisecting while retaining my patches.

    Is that going to work or am I going to have to repatch each time ?

    Basically can I use git to insert a patch into the middle of its delta history and then advance forward from there ?

    It is rapidly becoming obvious that competence with git could have big payback.

   

    











-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein