[fixed up Cc list that I dorked previously]
On Thu, Oct 11, 2007 at 09:06:42PM -0700, Linus Torvalds wrote>
> On Thu, 11 Oct 2007, Dave Jones wrote:
> >
> > I had hoped that git would be smart(tm) enough to figure out
> > that files had moved, and my changes in cpufreq.git would
> > somehow 're-route' to the right files, but it seems that
> > git isn't psychic, and gives up.
>
> Actually, git *is* psychic, and can almost certainly do it, but you need
> to help it a bit.
>
> Do a
>
> git config --global diff.renamelimit 0
>
> to tell git to not give up on just the sheer amount of renames.
>
> (The default git rename detection limit is really designed for
> smaller-memory machines)
This still gives me the same problem.
(14:21:29:davej@hera:src)$ git clone -l linus test
Initialized empty Git repository in /home/davej/src/test/.git/
0 blocks
Checking 23014 files out...
100% (23014/23014) done
(14:21:51:davej@hera:src)$ cd test/
(14:21:54:davej@hera:test)$ git config --global diff.renamelimit 0
(14:21:58:davej@hera:test)$ git pull ../cpufreqremote: Generating pack...
remote: Done counting 174 objects.
remote: Result has 116 objects.
remote: Deltifying 116 objects...
remote: 100% (116/116) done
remote: Total 116 (delta 105), reused 0 (delta 0)
Indexing 116 objects...
100% (116/116) done
Resolving 105 deltas...
100% (105/105) done
58 objects were added to complete this thin pack.
CONFLICT (delete/modify): arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c deleted in HEAD and modified in 9eb59573d4b86f347e6cd04f47a4c2082009fa58. Version 9eb59573d4b86f347e6cd04f47a4c2082009fa58 of arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c left in tree.
CONFLICT (delete/modify): arch/i386/kernel/cpu/cpufreq/cpufreq-nforce2.c deleted in HEAD and modified in 9eb59573d4b86f347e6cd04f47a4c2082009fa58. Version 9eb59573d4b86f347e6cd04f47a4c2082009fa58 of arch/i386/kernel/cpu/cpufreq/cpufreq-nforce2.c left in tree.
CONFLICT (delete/modify): arch/i386/kernel/cpu/cpufreq/e_powersaver.c deleted in HEAD and modified in 9eb59573d4b86f347e6cd04f47a4c2082009fa58. Version 9eb59573d4b86f347e6cd04f47a4c2082009fa58 of arch/i386/kernel/cpu/cpufreq/e_powersaver.c left in tree.
CONFLICT (delete/modify): arch/i386/kernel/cpu/cpufreq/elanfreq.c deleted in HEAD and modified in 9eb59573d4b86f347e6cd04f47a4c2082009fa58. Version 9eb59573d4b86f347e6cd04f47a4c2082009fa58 of arch/i386/kernel/cpu/cpufreq/elanfreq.c left in tree.
CONFLICT (delete/modify): arch/i386/kernel/cpu/cpufreq/gx-suspmod.c deleted in HEAD and modified in 9eb59573d4b86f347e6cd04f47a4c2082009fa58. Version 9eb59573d4b86f347e6cd04f47a4c2082009fa58 of arch/i386/kernel/cpu/cpufreq/gx-suspmod.c left in tree.
CONFLICT (delete/modify): arch/i386/kernel/cpu/cpufreq/longhaul.c deleted in HEAD and modified in 9eb59573d4b86f347e6cd04f47a4c2082009fa58. Version 9eb59573d4b86f347e6cd04f47a4c2082009fa58 of arch/i386/kernel/cpu/cpufreq/longhaul.c left in tree.
CONFLICT (delete/modify): arch/i386/kernel/cpu/cpufreq/p4-clockmod.c deleted in HEAD and modified in 9eb59573d4b86f347e6cd04f47a4c2082009fa58. Version 9eb59573d4b86f347e6cd04f47a4c2082009fa58 of arch/i386/kernel/cpu/cpufreq/p4-clockmod.c left in tree.
CONFLICT (delete/modify): arch/i386/kernel/cpu/cpufreq/powernow-k6.c deleted in HEAD and modified in 9eb59573d4b86f347e6cd04f47a4c2082009fa58. Version 9eb59573d4b86f347e6cd04f47a4c2082009fa58 of arch/i386/kernel/cpu/cpufreq/powernow-k6.c left in tree.
CONFLICT (delete/modify): arch/i386/kernel/cpu/cpufreq/powernow-k7.c deleted in HEAD and modified in 9eb59573d4b86f347e6cd04f47a4c2082009fa58. Version 9eb59573d4b86f347e6cd04f47a4c2082009fa58 of arch/i386/kernel/cpu/cpufreq/powernow-k7.c left in tree.
CONFLICT (delete/modify): arch/i386/kernel/cpu/cpufreq/powernow-k8.c deleted in HEAD and modified in 9eb59573d4b86f347e6cd04f47a4c2082009fa58. Version 9eb59573d4b86f347e6cd04f47a4c2082009fa58 of arch/i386/kernel/cpu/cpufreq/powernow-k8.c left in tree.
CONFLICT (delete/modify): arch/i386/kernel/cpu/cpufreq/sc520_freq.c deleted in HEAD and modified in 9eb59573d4b86f347e6cd04f47a4c2082009fa58. Version 9eb59573d4b86f347e6cd04f47a4c2082009fa58 of arch/i386/kernel/cpu/cpufreq/sc520_freq.c left in tree.
CONFLICT (delete/modify): arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c deleted in HEAD and modified in 9eb59573d4b86f347e6cd04f47a4c2082009fa58. Version 9eb59573d4b86f347e6cd04f47a4c2082009fa58 of arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c left in tree.
CONFLICT (delete/modify): arch/i386/kernel/cpu/cpufreq/speedstep-ich.c deleted in HEAD and modified in 9eb59573d4b86f347e6cd04f47a4c2082009fa58. Version 9eb59573d4b86f347e6cd04f47a4c2082009fa58 of arch/i386/kernel/cpu/cpufreq/speedstep-ich.c left in tree.
CONFLICT (delete/modify): arch/i386/kernel/cpu/cpufreq/speedstep-smi.c deleted in HEAD and modified in 9eb59573d4b86f347e6cd04f47a4c2082009fa58. Version 9eb59573d4b86f347e6cd04f47a4c2082009fa58 of arch/i386/kernel/cpu/cpufreq/speedstep-smi.c left in tree.
Auto-merged arch/powerpc/platforms/cell/cbe_cpufreq.c
Automatic merge failed; fix conflicts and then commit the result.
The git on master.kernel.org (1.5.3.4) is pretty recent, so I don't think
that's the problem, is it?
Dave
--
http://www.codemonkey.org.uk
On Fri, 12 Oct 2007, Dave Jones wrote:
>
> The git on master.kernel.org (1.5.3.4) is pretty recent, so I don't think
> that's the problem, is it?
It may be that the "renamelimit" thing didn't go into the stable branch at
all. If you build your git from the current HEAD, it should work.
Or just point me to the thing, and I'll see if I can merge it.
Linus
On Fri, Oct 12, 2007 at 02:58:24PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 12 Oct 2007, Dave Jones wrote:
> >
> > The git on master.kernel.org (1.5.3.4) is pretty recent, so I don't think
> > that's the problem, is it?
>
> It may be that the "renamelimit" thing didn't go into the stable branch at
> all. If you build your git from the current HEAD, it should work.
>
> Or just point me to the thing, and I'll see if I can merge it.
pull req below. If it turns out to be more trouble than its worth,
let me know, and I'll fix up the patches by hand, and generate
a new git tree. (If it comes to that, I understand Thomas has a script
that may help).
Dave
Please pull from ..
master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq.git/
arch/arm/mach-imx/cpufreq.c | 1 -
arch/arm/mach-sa1100/cpu-sa1110.c | 1 -
arch/arm/plat-omap/cpu-omap.c | 1 -
arch/blackfin/mach-bf533/cpu.c | 2 -
arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c | 1 -
arch/i386/kernel/cpu/cpufreq/cpufreq-nforce2.c | 1 -
arch/i386/kernel/cpu/cpufreq/e_powersaver.c | 1 -
arch/i386/kernel/cpu/cpufreq/elanfreq.c | 1 -
arch/i386/kernel/cpu/cpufreq/gx-suspmod.c | 1 -
arch/i386/kernel/cpu/cpufreq/longhaul.c | 5 ++-
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c | 1 -
arch/i386/kernel/cpu/cpufreq/powernow-k6.c | 1 -
arch/i386/kernel/cpu/cpufreq/powernow-k7.c | 2 -
arch/i386/kernel/cpu/cpufreq/powernow-k8.c | 13 +++----
arch/i386/kernel/cpu/cpufreq/sc520_freq.c | 1 -
arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c | 1 -
arch/i386/kernel/cpu/cpufreq/speedstep-ich.c | 1 -
arch/i386/kernel/cpu/cpufreq/speedstep-smi.c | 1 -
arch/ia64/kernel/cpufreq/acpi-cpufreq.c | 2 -
arch/powerpc/platforms/cell/cbe_cpufreq.c | 2 -
arch/powerpc/platforms/pasemi/cpufreq.c | 2 -
arch/powerpc/platforms/powermac/cpufreq_32.c | 1 -
arch/powerpc/platforms/powermac/cpufreq_64.c | 1 -
arch/sh/kernel/cpufreq.c | 1 -
arch/sparc64/kernel/us2e_cpufreq.c | 1 -
drivers/cpufreq/Kconfig | 27 ++++++++++++--
drivers/cpufreq/cpufreq.c | 34 +++++++++++++++---
drivers/cpufreq/cpufreq_conservative.c | 19 +++++-----
drivers/cpufreq/cpufreq_ondemand.c | 22 +++++-------
drivers/cpufreq/cpufreq_stats.c | 18 ++++-----
include/linux/cpufreq.h | 39 +++++++++++++++++---
31 files changed, 119 insertions(+), 86 deletions(-)
commit 9eb59573d4b86f347e6cd04f47a4c2082009fa58
Author: Andi Kleen <[email protected]>
Date: Wed Oct 10 02:18:27 2007 +0200
[CPUFREQ] Don't take semaphore in cpufreq_quick_get()
I don't see any reason to take an expensive lock in cpufreq_quick_get()
Reading policy->cur is a single atomic operation and after
the lock is dropped again the state could change any time anyways.
So don't take the lock in the first place.
This also makes this function interrupt safe which is useful
for some code of mine.
Signed-off-by: Andi Kleen <[email protected]>
Cc: "Pallipadi, Venkatesh" <[email protected]>
Signed-off-by: Dave Jones <[email protected]>
commit 562d94d98f7032bdc4a99d9124a78a543dbea225
Author: Mark Langsdorf <[email protected]>
Date: Fri Aug 3 14:09:05 2007 -0500
[CPUFREQ] Support different families in fid/did to frequency conversion
The equation to find the frequency given the fid and did is family dependant.
Acked-by: Mark Langsdorf <[email protected]>
Signed-off-by: Joachim Deguara <[email protected]>
Signed-off-by: Dave Jones <[email protected]>
commit 55395ae72b6e5ae614d28df74158c47454652583
Author: Satyam Sharma <[email protected]>
Date: Tue Oct 2 13:28:15 2007 -0700
[CPUFREQ] cpufreq_stats: misc cpuinit section annotations
* Stop referencing the callback directly from the __init and __exit
functions of this driver, and instead explicitly call
cpufreq_update_policy() et al. This enables the callback function
to be marked as __cpuinit (and the notifier_block __cpuinitdata),
thereby saving space when HOTPLUG_CPU=n. This also enables us to
use other tricks to replace __cpuinit{data} in future.
* cpufreq_stats_free_table() is only called from __cpuinit or __exit
marked functions, making it an ideal candidate for __cpuexit.
* Fix missing space in the module description
Signed-off-by: Satyam Sharma <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Dave Jones <[email protected]>
commit 6070b5de50ab5e3f810628a9cbb04deecf30a85f
Author: Satyam Sharma <[email protected]>
Date: Tue Oct 2 13:28:15 2007 -0700
[CPUFREQ] implement !CONFIG_CPU_FREQ stub for cpufreq_unregister_notifier()
Callsites such as arch/powerpc/oprofile/op_model_cell.c are having to
open-code #ifdef CONFIG_CPU_FREQ only to be able to get at the full definition
of cpufreq_unregister_notifier(), because no empty stub is available for the
!CONFIG_CPU_FREQ case. Let's provide one, to be able to remove such #ifdef's
from the rest of the kernel tree -- those will come in a subsequent patch.
Signed-off-by: Satyam Sharma <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Dave Jones <[email protected]>
commit dd184a01b8ece6bac2f7a63de99a4a4d29552746
Author: Satyam Sharma <[email protected]>
Date: Tue Oct 2 13:28:14 2007 -0700
[CPUFREQ] mark hotplug notifier callback as __cpuinit
The notifier_block is already __cpuinitdata, thereby allowing us to safely
mark the callback function as __cpuinit also, thereby saving space when
HOTPLUG_CPU=n.
Signed-off-by: Satyam Sharma <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Dave Jones <[email protected]>
commit 6afde10c3f58cc3ac593f5b4505b8b1cf719f5d6
Author: Thomas Renninger <[email protected]>
Date: Tue Oct 2 13:28:13 2007 -0700
[CPUFREQ] Only check for transition latency on problematic governors (kconfig fix)
Cc: Adrian Bunk <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Dave Jones <[email protected]>
commit 1c2562459faedc35927546cfa5273ec6c2884cce
Author: Thomas Renninger <[email protected]>
Date: Tue Oct 2 13:28:12 2007 -0700
[CPUFREQ] allow ondemand and conservative cpufreq governors to be used as default
Depending on the transition latency of the HW for cpufreq switches, the
ondemand or conservative governor cannot be used with certain cpufreq
drivers. Still the ondemand should be the default governor on a wide range
of systems. This patch allows this and lets the governor fallback to the
performance governor at cpufreq driver load time, if the driver does not
support fast enough frequency switching.
Main benefit is that on e.g. installation or other systems without
userspace support a working dynamic cpufreq support can be achieved on most
systems by simply loading the cpufreq driver. This is especially essential
for recent x86(_64) laptop hardware which may rely on working dynamic
cpufreq OS support.
Signed-off-by: Thomas Renninger <[email protected]>
Signed-off-by: Venkatesh Pallipadi <[email protected]>
Cc: Russell King <[email protected]>
Cc: Bryan Wu <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: "Luck, Tony" <[email protected]>
Cc: Paul Mackerras <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Paul Mundt <[email protected]>
Cc: "David S. Miller" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Dave Jones <[email protected]>
commit 8122c6cea033e8034e99d3b10a4e3f377ce23994
Author: Thomas Renninger <[email protected]>
Date: Tue Oct 2 13:28:09 2007 -0700
[CPUFREQ] move policy's governor initialisation out of low-level drivers into cpufreq core
Signed-off-by: Thomas Renninger <[email protected]>
Signed-off-by: Venkatesh Pallipadi <[email protected]>
Cc: Russell King <[email protected]>
Cc: Bryan Wu <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: "Luck, Tony" <[email protected]>
Cc: Paul Mackerras <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Paul Mundt <[email protected]>
Cc: "David S. Miller" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Dave Jones <[email protected]>
commit a09d60a622ea4a3592dc6836e709d4a7a4ed4025
Author: Rafał Bilski <[email protected]>
Date: Wed Sep 26 17:08:14 2007 +0200
[CPUFREQ] Longhaul - Add support for PM133 northbridge
Add support for PM133 northbridge. Tested by Sylvain Ferrand.
Signed-off-by: Rafal Bilski <[email protected]>
Signed-off-by: Dave Jones <[email protected]>
commit c925401b6dc2229adbb15b2f3c9f0f2d9253a5d5
Author: Yinghai Lu <[email protected]>
Date: Wed Aug 22 18:44:20 2007 -0700
[CPUFREQ] x86: use num_online_nodes to get physical cpus numbers for
powernow_k8
[PATCH] x86: use num_online_nodes to get physical cpus numbers for powernow_k8
For opteron based system, don't assume all physical cpus have the same booted cpus even same cores. esp for downcore case.
Signed-off-by: Yinghai Lu <yinghai.sun.com>
Signed-off-by: Dave Jones <[email protected]>
--
http://www.codemonkey.org.uk
On Fri, 12 Oct 2007, Dave Jones wrote:
>
> pull req below. If it turns out to be more trouble than its worth,
It merged totally automatically, no trouble what-so-ever:
Renamed arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c => arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
Auto-merged arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
Renamed arch/i386/kernel/cpu/cpufreq/longhaul.c => arch/x86/kernel/cpu/cpufreq/longhaul.c
Auto-merged arch/x86/kernel/cpu/cpufreq/longhaul.c
Auto-merged arch/powerpc/platforms/cell/cbe_cpufreq.c
Merge made by recursive.
I think it was just unlucky that the particular version of git you have
probably hit exactly in the window of "limited rename detection" *and*
lacking the config switch to turn off the limiter.
Linus
On Fri, Oct 12, 2007 at 03:43:46PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 12 Oct 2007, Dave Jones wrote:
> >
> > pull req below. If it turns out to be more trouble than its worth,
>
> It merged totally automatically, no trouble what-so-ever:
>
> Renamed arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c => arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
> Auto-merged arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
> Renamed arch/i386/kernel/cpu/cpufreq/longhaul.c => arch/x86/kernel/cpu/cpufreq/longhaul.c
> Auto-merged arch/x86/kernel/cpu/cpufreq/longhaul.c
> Auto-merged arch/powerpc/platforms/cell/cbe_cpufreq.c
> Merge made by recursive.
>
> I think it was just unlucky that the particular version of git you have
> probably hit exactly in the window of "limited rename detection" *and*
> lacking the config switch to turn off the limiter.
Awesome! Thanks for doing that.
One other git quirk that I'm not sure how to work around btw..
Something I find useful is to just do for eg..
git log arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
from time to time, to figure out when certain changes happened,
or even to grep for something in a changelog.
With that file moved, git refuses to tell me about the log
of a file that doesn't exist, and the log of the moved
file in arch/x86 just has a single commit, detailing the move.
Is there an easy way to get the complete log of a file?
Dave
--
http://www.codemonkey.org.uk
On Fri, 12 Oct 2007, Dave Jones wrote:
>
> Something I find useful is to just do for eg..
>
> git log arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>
> from time to time, to figure out when certain changes happened,
> or even to grep for something in a changelog.
> With that file moved, git refuses to tell me about the log
> of a file that doesn't exist, and the log of the moved
> file in arch/x86 just has a single commit, detailing the move.
>
> Is there an easy way to get the complete log of a file?
The "--follow" flag will follow renames when doing a log, so a simple
git log --follow arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
will do it.
[ Although I actually introduced a bug in that last week, so if it gives
empty output for you, add a "--stat" to get a diffstat (or "-p" to get
the whole patch) to work around a stupid mistake. That bug is in both
1.5.3.3 and 1.5.3.4 - and Junio happens to be away for two weeks, so
it's not fixed in any release yet. I have a trivial patch for it if you
care, but the "use -p" workaround is usually what you want to do anyway,
which is probably why nobody even noticed it was broken! ]
Linus
On Fri, Oct 12, 2007 at 04:14:54PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 12 Oct 2007, Dave Jones wrote:
> >
> > Something I find useful is to just do for eg..
> >
> > git log arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
> >
> > from time to time, to figure out when certain changes happened,
> > or even to grep for something in a changelog.
> > With that file moved, git refuses to tell me about the log
> > of a file that doesn't exist, and the log of the moved
> > file in arch/x86 just has a single commit, detailing the move.
> >
> > Is there an easy way to get the complete log of a file?
>
> The "--follow" flag will follow renames when doing a log, so a simple
>
> git log --follow arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>
> will do it.
Hrmm.
$ git log --follow arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
fatal: ambiguous argument 'arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c':
unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
Using --follow on the arch/x86 post-merge file gives me even less info
than it does without it :)
> [ Although I actually introduced a bug in that last week, so if it gives
> empty output for you, add a "--stat" to get a diffstat (or "-p" to get
> the whole patch) to work around a stupid mistake. That bug is in both
> 1.5.3.3 and 1.5.3.4 - and Junio happens to be away for two weeks, so
> it's not fixed in any release yet. I have a trivial patch for it if you
> care, but the "use -p" workaround is usually what you want to do anyway,
> which is probably why nobody even noticed it was broken! ]
Is what I'm seeing above indicative of this bug ? Or something else?
Adding -p or --stat makes no difference at all.
Dave
--
http://www.codemonkey.org.uk
On Fri, Oct 12, 2007 at 08:11:53PM -0400, Dave Jones wrote:
> On Fri, Oct 12, 2007 at 04:14:54PM -0700, Linus Torvalds wrote:
> >
> >
> > On Fri, 12 Oct 2007, Dave Jones wrote:
> > >
> > > Something I find useful is to just do for eg..
> > >
> > > git log arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
> > >
> > > from time to time, to figure out when certain changes happened,
> > > or even to grep for something in a changelog.
> > > With that file moved, git refuses to tell me about the log
> > > of a file that doesn't exist, and the log of the moved
> > > file in arch/x86 just has a single commit, detailing the move.
> > >
> > > Is there an easy way to get the complete log of a file?
> >
> > The "--follow" flag will follow renames when doing a log, so a simple
> >
> > git log --follow arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
> >
> > will do it.
>
> Hrmm.
>
> $ git log --follow arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
> fatal: ambiguous argument 'arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c':
> unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions
>
> Using --follow on the arch/x86 post-merge file gives me even less info
> than it does without it :)
duh.
git log --stat --follow arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
works just fine. Thanks.
(was running it on the old path)
Dave
--
http://www.codemonkey.org.uk
On Fri, 12 Oct 2007, Dave Jones wrote:
>
> $ git log --follow arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
> fatal: ambiguous argument 'arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c':
> unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions
Duh. You need to use the current name, of course.
git log --follow arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
gives me the proper output.
> Is what I'm seeing above indicative of this bug ? Or something else?
> Adding -p or --stat makes no difference at all.
Try it with the right path.
Linus