From: "David H. Lynch Jr." <dhlii@dlasys.net>
To: linuxppc-embedded@ozlabs.org
Subject: Re: how to get individual patches
Date: Fri, 14 Jul 2006 14:13:23 -0400 [thread overview]
Message-ID: <44B7DEC3.1090308@dlasys.net> (raw)
In-Reply-To: <528646bc0606280209m4ce91cb0wc3cab2f2d3aec1a7@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 2991 bytes --]
next prev parent reply other threads:[~2006-07-14 18:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-27 18:38 Lite5200 MTD partitions in 2.6 build Rowan, Chad
2006-06-27 19:24 ` White
2006-06-28 7:49 ` how to get individual patches David H. Lynch Jr.
2006-06-28 8:32 ` Alex Zeffertt
2006-06-28 16:22 ` David H. Lynch Jr.
2006-06-28 9:09 ` Grant Likely
2006-06-28 16:18 ` David H. Lynch Jr.
2006-07-14 18:13 ` David H. Lynch Jr. [this message]
2006-07-14 18:22 ` Grant Likely
2006-07-17 3:46 ` David H. Lynch Jr.
2006-07-17 5:30 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44B7DEC3.1090308@dlasys.net \
--to=dhlii@dlasys.net \
--cc=dhlii@comcast.net \
--cc=linuxppc-embedded@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.