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
seanRe: how to trace the patch?
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
Linus TorvaldsRe: how to trace the patch?
On Thu, 27 Apr 2006, sean wrote:
Show 10 quoted lines
> > $ 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?
Thanks a lot. I'll enjoy it.
Regards, -Aubrey
On 4/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
Show 47 quoted lines
> > > 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 >