For quite some time I'm trying to understand if it's possible
to extract changes from some subsystem's GIT tree compared to
some version of linux kernel.
For example, let's say I want to see if my SATA controller will
work with current libata, but without all the pain of trying
current 2.6.19-pre/rc instabilities. Libata changes are quite
local for the subsystem, so in theory, or at least how I see
it, that should be possible.
So I have 3 remote branches in my local GIT tree:
o origin which points to Linus's 2.6.19-pre
o libata, which is current libata tree
o 2.6.18 release -- the kernel I'm running right now.
I want to get changes *for libata subsystem* in origin or
libata (libata is just changes which are on the way to Linus,
and current difference is very minor), to apply against 2.6.18.
Ie, in short, changes which went to origin *from* libata.
Is it possible?
Thanks.
/mjt
On Wed, Oct 11, 2006 at 10:54:50PM +0400, Michael Tokarev wrote:
> For quite some time I'm trying to understand if it's possible
> to extract changes from some subsystem's GIT tree compared to
> some version of linux kernel.
>
> For example, let's say I want to see if my SATA controller will
> work with current libata, but without all the pain of trying
> current 2.6.19-pre/rc instabilities. Libata changes are quite
> local for the subsystem, so in theory, or at least how I see
> it, that should be possible.
>
> So I have 3 remote branches in my local GIT tree:
>
> o origin which points to Linus's 2.6.19-pre
> o libata, which is current libata tree
> o 2.6.18 release -- the kernel I'm running right now.
>
> I want to get changes *for libata subsystem* in origin or
> libata (libata is just changes which are on the way to Linus,
> and current difference is very minor), to apply against 2.6.18.
> Ie, in short, changes which went to origin *from* libata.
>
> Is it possible?
If I understand what you want to do, you just have to do this :
$ git-checkout 2.6.18
$ git-pull . libata
This will merge in 2.6.18 everything that's in libata. If you
want to check before what will be merged :
$ git-log 2.6.18..libata
or :
$ git-diff 2.6.18..libata
or also to review the patches one at a time :
$ git-format-patch -k -m 2.6.18..libata
then read all the files.
Hoping it helps
willy
Michael Tokarev <[email protected]> :
[...]
> Is it possible?
git diff 2.6.18..origin -- drivers/ata ?
Experiment with options for rename.
--
Ueimor
Willy Tarreau wrote:
> On Wed, Oct 11, 2006 at 10:54:50PM +0400, Michael Tokarev wrote:
[]
>> o origin which points to Linus's 2.6.19-pre
>> o libata, which is current libata tree
>> o 2.6.18 release -- the kernel I'm running right now.
>>
>> I want to get changes *for libata subsystem* in origin or
>> libata (libata is just changes which are on the way to Linus,
>> and current difference is very minor), to apply against 2.6.18.
>> Ie, in short, changes which went to origin *from* libata.
>>
>> Is it possible?
>
> If I understand what you want to do, you just have to do this :
>
> $ git-checkout 2.6.18
> $ git-pull . libata
>
> This will merge in 2.6.18 everything that's in libata. If you
It will merge everything wich is in current 2.6.19-pre, too.
Ie, it will be current 2.6.19 tree basically, or 'origin' in
my case.
(currently, the only 2 differences between origin and libata
is a tiny bugfix and winbond driver, so using libata or origin
here is basically the same thing).
But I wanted to _omit_ everything _but_ libata - stuff which
*come* to Linus's tree from libata) from the diff.
So it looks like the key idea is to find which commits are
relevant. With libata as an example, it's relatively easy -
git-diff 2.6.18..libata drivers/ata
( or 2.6.18..origin drivers/ata -- as the two trees are
almost the same currently), plus some includes.
Ie, some other ways needs to be used to *identify* which parts
of the whole thing is needed, in this example it's easy as
everything is located in the same dir.
With more complex changes, things aren't that simple if at all
possible, BUT there's almost no chances that the resulting
"patched-2.6.18" will ever compile after trying to apply that
complex changes, anyway ;)
But thanks anyway ;)
/mjt
Francois Romieu wrote:
> Michael Tokarev <[email protected]> :
> [...]
>> Is it possible?
>
> git diff 2.6.18..origin -- drivers/ata ?
Yeah, -- the idea is to identify which changes are relevant
using some other criteria, not "git tree placement" or something
like that -- example is to use directory as you suggested (plus
relevant includes).
> Experiment with options for rename.
Yeah -- like git-diff-tree -M, I used it before (for this libata stuff
as well), and even wrote a tiny shell wrapper around patch(1) to
apply git-diff-tree -M -generated patch - first pass is to handle
renames in shell, and second pass is to apply the patch itself... ;)
Thanks.
/mjt