how to trace the patch?

how to trace the patch?

[Aubrey]

Hi all,

When I update the kernel git tree a few days later, you know, there
could be a lot of patches. Then I found one file changed, how can I
know which patch the modification belong to?
How can I find the patch?
Many thanks,

Regards,
-Aubrey

Re: how to trace the patch?

[sean]

On Thu, 27 Apr 2006 18:06:09 +0800
Aubrey <aubreylee@gmail.com> wrote:

> When I update the kernel git tree a few days later, you know, there
> could be a lot of patches. Then I found one file changed, how can I
> know which patch the modification belong to?
> How can I find the patch?

Hi Aubrey,

$ git log -- <filename>

To see a list of commits that affected the file you're interested in.

$ git log -p -- <filename>

Will include a diff after each commit showing you how the file was
changed.  And if you want to see what other changes happened in each
commit that modified your file, add "--full-diff" to the command above.

Note that you can also replace the <filename> with a <directory> 
to see a list of commits that affected any file below that directory.

HTH,
Sean

Re: how to trace the patch?

[Linus Torvalds]

On Thu, 27 Apr 2006, sean wrote:
> 
> $ git log -- <filename>
> 
> To see a list of commits that affected the file you're interested in.
> 
> $ git log -p -- <filename>
> 
> Will include a diff after each commit showing you how the file was
> changed.  And if you want to see what other changes happened in each
> commit that modified your file, add "--full-diff" to the command above.

Side note: the "git log -p" thing only works with git 1.3.0+, and even 
without the "-p", old versions will be very slow.

So if you have anything older than 1.3.0, you're likely better off using 
"git whatchanged [-p] -- <filename>".

Also, regardless of which one you use, it's worth pointing out that:

 - for tracking multiple files, just use more than one filename, and you 
   can also use a directory name. 

 - you can combine this with all the normal revision limiting rules, which 
   is often useful when you know you're not interested in stuff you've 
   already seen.

For example, if you have just done a "git pull" and you noticed that a 
file (or set of files) you cared about changed - or you just wonder _if_ 
it changed - you can do something like

	gitk ORIG_HEAD.. -- drivers/scsi/ include/scsi/

to see what changed due to the pull within those files. Useful whether 
you're tracking certain subsystems, individual drivers, architectures, 
whatever.. It can be useful also just to split the logs up (ie maybe 
you're not interested in anything in particular, but you do a "git log" 
and see something that strikes your fancy, you can decide to see what 
_else_ changed in that area).

And instead of "gitk", use "git log -p" or "git whatchanged" or whatever. 
It's all the same thing, just different ways of looking at it.

		Linus

Re: how to trace the patch?

[Aubrey]

Thanks a lot.
I'll enjoy it.

Regards,
-Aubrey

On 4/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Thu, 27 Apr 2006, sean wrote:
> >
> > $ git log -- <filename>
> >
> > To see a list of commits that affected the file you're interested in.
> >
> > $ git log -p -- <filename>
> >
> > Will include a diff after each commit showing you how the file was
> > changed.  And if you want to see what other changes happened in each
> > commit that modified your file, add "--full-diff" to the command above.
>
> Side note: the "git log -p" thing only works with git 1.3.0+, and even
> without the "-p", old versions will be very slow.
>
> So if you have anything older than 1.3.0, you're likely better off using
> "git whatchanged [-p] -- <filename>".
>
> Also, regardless of which one you use, it's worth pointing out that:
>
>  - for tracking multiple files, just use more than one filename, and you
>   can also use a directory name.
>
>  - you can combine this with all the normal revision limiting rules, which
>   is often useful when you know you're not interested in stuff you've
>   already seen.
>
> For example, if you have just done a "git pull" and you noticed that a
> file (or set of files) you cared about changed - or you just wonder _if_
> it changed - you can do something like
>
>        gitk ORIG_HEAD.. -- drivers/scsi/ include/scsi/
>
> to see what changed due to the pull within those files. Useful whether
> you're tracking certain subsystems, individual drivers, architectures,
> whatever.. It can be useful also just to split the logs up (ie maybe
> you're not interested in anything in particular, but you do a "git log"
> and see something that strikes your fancy, you can decide to see what
> _else_ changed in that area).
>
> And instead of "gitk", use "git log -p" or "git whatchanged" or whatever.
> It's all the same thing, just different ways of looking at it.
>
>                Linus
>