On Wed, Feb 28, 2018 at 10:16:21AM -0800, Junio C Hamano wrote:
> Adam Borowski <kilobyte@xxxxxxxxxx> writes:
>
> > Desktops and servers tend to have no power sensor, thus on_ac_power returns
> > 255 ("unknown").
> >
> > If that tool returns "unknown", there's no point in querying other sources
> > as it already queried them, and is smarter than us (can handle multiple
> > adapters).
>
> The explanation talks about the exit status 255 being special and
> serves to signal "there is no point continuing, and it is OK to
> assume we are not on batttery", while the code says that anything
> but exit status 1 can be treated as such. Which is correct?
As the man page says:
# EXIT STATUS
# 0 (true) System is on mains power
# 1 (false) System is not on mains power
# 255 (false) Power status could not be determined
0 usually means a laptop on AC power, 255 is for a typical desktop.
The current code can't return 2 or any other unexpected value, but if it
ever does, an unknown error should probably be treated same as 255 unknown.
Thus, gc should be avoided only if the return code is 1.
As for the second paragraph, I meant that on_ac_power already queried all
sources this hook knows about (other than /usr/bin/pmset which is OSX
only[1]), thus if the answer is "unknown", continuing to query is redundant.
If that's unclear, do you have some other wording in mind?
Also, it's good to trust on_ac_power, as it'll get updated whenever new
quirks of power management get known: I heard allegations that some boards
say "USB" instead of "Mains", which should count the same for our
purposes[2]. It's not reasonable to update consumers such as git instead of
a single system-provided tool.
One worry is that, if on_ac_power is not installed, other sources known by
this hook likewise assume that unknown means battery. And for example on
Debian, powermgmt-base (which is where on_ac_power lives) is no longer
installed by default. This suggests this patch needs to be extended to
cover the other sources as well, but let's discuss this first. Extra
commits are cheap...
> > Reported by: Xin Li <delphij@xxxxxxxxxx>
> > Signed-off-by: Adam Borowski <kilobyte@xxxxxxxxxx>
> > ---
> > contrib/hooks/pre-auto-gc-battery | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/contrib/hooks/pre-auto-gc-battery b/contrib/hooks/pre-auto-gc-battery
> > index 6a2cdebdb..7ba78c4df 100755
> > --- a/contrib/hooks/pre-auto-gc-battery
> > +++ b/contrib/hooks/pre-auto-gc-battery
> > @@ -17,7 +17,7 @@
> > # ln -sf /usr/share/git-core/contrib/hooks/pre-auto-gc-battery \
> > # hooks/pre-auto-gc
> >
> > -if test -x /sbin/on_ac_power && /sbin/on_ac_power
> > +if test -x /sbin/on_ac_power && (/sbin/on_ac_power;test $? -ne 1)
> > then
> > exit 0
> > elif test "$(cat /sys/class/power_supply/AC/online 2>/dev/null)" = 1
>
[1]. I don't know if there's an implementation of on_ac_power for OSX, but
if there is, it is reasonable to assume it uses or emulates pmset.
[2]. Technically, that's _dc_ not ac power, but as batteries use a different
interface, in the vast majority of cases USB power can be considered
non-rationed. You can power it from an unplugged laptop or from a
powerbank, but that's no different from "mains" that come from an unplugged
UPS with no or unsupported control link.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄⠀⠀⠀⠀ A master species delegates.
