[Top] [All Lists]

Re: Version control question.

To: Kaz Kylheku <>
Subject: Re: Version control question.
From: Ralf Baechle <>
Date: Fri, 11 Aug 2006 23:32:14 +0100
In-reply-to: <66910A579C9312469A7DF9ADB54A8B7D33AFE9@exchange.ZeugmaSystems.local>
Original-recipient: rfc822;
References: <66910A579C9312469A7DF9ADB54A8B7D33AFE9@exchange.ZeugmaSystems.local>
User-agent: Mutt/
On Fri, Aug 11, 2006 at 02:31:49PM -0700, Kaz Kylheku wrote:

> Is there any document that makes the linux-mips configuration management
> structure more obvious?

There is  If that doesn't answer
your questions, let me know what you're missing and if I find the time
I'll add it.  Or just add it yourself to the wiki.

> I see that the 2.6.16 and 2.6.17 lines are in fact parallel branches, so
> that is newer than 2.6.17.


> If something is broken in 2.6.17 but isn't in, what's the best
> way to find it?

You can use git bisect to do that on a clean that is unmodified tree:

$ git bisect start
$ git bisect bad linux-2.6.17
$ git bisect good linux-

git will then checkout a tree that is about in the middle between the
good and bad version.  Build and test it, then either tell git

$ git bisect good


$ git bisect bad

depending on the outcome of your test.  Continue you've shurnk the
interval to a single version which is when git will tell you which
commit broke things.

Once you're finished you tell git to cleanup the tree from all the
bisecting stuff:

$ git bisect reset

> Just compare to the closest parallel 2.6.17.x to see what the
> differences are?

git bisect is handy for finding a change even for relative beginners,
while starring at a diff is often much faster.  You can get a diff
between two tagged versions in git like:

$ git diff linux-


<Prev in Thread] Current Thread [Next in Thread>