Re: Move to git is imminent - awaiting Stefan's approval

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: address@hidden,
>     address@hidden,
>     address@hidden,
>     address@hidden,
>     address@hidden
> Date: Wed, 08 Jan 2014 12:47:29 +0900
> 
> Eli Zaretskii writes:
>  > I did read the documentation.  The docs of gc mentions git-repack, so
>  > I thought the former runs the latter.  What part did I miss?
> 
> The fact that the documentation clearly puts conditions on when git-gc
> runs git-repack.

I wouldn't qualify the gc manpage as "clear" on this matter, see
below.  But given what it does say, I _guessed_ that "git gc" _might_
run git-repack, and asked whether that wasn't so.  Why that pissed you
off I don't know.  You seem to have deduced a different conclusion,
but IMO that's just one more evidence that the man page is not really
clear on this matter.

>  > And how was I supposed to know from this whether git-repack will or
>  > won't be run, what with the word "repack" explicitly in this text (and
>  > in other parts of that man page)?
> 
> Huh?  If there's a condition on whether it runs, then presumably
> sometimes it doesn't run.

AFAIU, you refer to this part of your previous message:

> Specifically, according to the help, git-gc removes garbage (in the
> usual sense of a tracing collector) and "compresses" (ie, packs) loose
> objects using delta compression (and then the result is deflated as
> with loose objects, I believe).  It will repack the packs into *one*
> pack (presumably with better delta compression) if the number of packs
> is greater than the value of gc.autopacklimit (in .git/config;
> default: 50).

However, this comes from the part in the man page that describes the
"--auto" option to gc.  I didn't use and didn't mean to use that
option, so the above is not necessarily relevant to "git gc".

But even if this description is relevant when --auto is not used,
the above says that repacking will sometimes happen.

As to what happens regardless of any options, the man page says just
this:

  DESCRIPTION

    Runs a number of housekeeping tasks within the current repository,
    such as compressing file revisions (to reduce disk space and
    increase performance) and removing unreachable objects which may
    have been created from prior invocations of git add.

This says "such as", which doesn't imply an exhaustive list of tasks.
Moreover, it never says that "compressing file revisions" and
"removing unreachable objects" is not done by git-repack.  So the
above description does not contradict my conclusion, and definitely
doesn't present exact description of the conditions under which gc
will run repack.  Perhaps if I knew exactly what repack does, I could
have filled the voids, but I don't.

Finally, the "Configuration" section has this, among the rest:

  The optional configuration variable gc.packrefs determines if git gc
  runs git pack-refs. This can be set to "notbare" to enable it within
  all non-bare repos or it can be set to a boolean value. This
  defaults to true.

  The optional configuration variable gc.aggressiveWindow controls how
  much time is spent optimizing the delta compression of the objects
  in the repository when the --aggressive option is specified. The
  larger the value, the more time is spent optimizing the delta
  compression. See the documentation for the --window' option in
  git-repack(1) for more details. This defaults to 250.

Both of these configuration settings explicitly mention packing and/or
repacking.  Again, without knowing exactly what repack does, there's
no clarity here whether pack-refs is related to repack in any way,
shape or form (looking in the sources resolves this, see below).

Given these hints, IMO it was a reasonable guess that gc does run
repack at least under some conditions, when --auto is not used.  Since
these conditions are not defined completely by the man page, it was my
guess that gc, with or without the --aggressive option, might run
repack.  As it turns out, the second part is surely true.

> You read the source?  I find that hard to believe.

I didn't read the source in this case, only the documentation.

I don't understand the "hard to believe" part, though: I do have the
git's git repo on my disk, and you could easily imagine that I'm not
new to reading sources.

Having now looked in the sources, this is what I see:

        if (pack_refs && run_command_v_opt(pack_refs_cmd.argv, RUN_GIT_CMD))
                return error(FAILED_RUN, pack_refs_cmd.argv[0]);

        if (run_command_v_opt(reflog.argv, RUN_GIT_CMD))
                return error(FAILED_RUN, reflog.argv[0]);

        if (run_command_v_opt(repack.argv, RUN_GIT_CMD))
                return error(FAILED_RUN, repack.argv[0]);

        if (prune_expire) {
                argv_array_push(&prune, prune_expire);
                if (quiet)
                        argv_array_push(&prune, "--no-progress");
                if (run_command_v_opt(prune.argv, RUN_GIT_CMD))
                        return error(FAILED_RUN, prune.argv[0]);
        }

        if (run_command_v_opt(rerere.argv, RUN_GIT_CMD))
                return error(FAILED_RUN, rerere.argv[0]);

My reading of this is that "git gc" runs, in sequence, pack-refs
(conditioned on gc.packrefs), reflog, repack, prune (conditioned on
the --prune option), and finally rerere.  IOW, "git gc" does run
repack.  The only difference between --aggressive and non-aggressive
modes is here:

        if (aggressive) {
                argv_array_push(&repack, "-f");
                argv_array_push(&repack, "--depth=250");
                if (aggressive_window > 0)
                        argv_array_pushf(&repack, "--window=%d", 
aggressive_window);
        }

That is, --aggressive just passes the -f switch to git-repack, which
tells it not to reuse deltas (i.e. recompute them anew, AFAIU).

> (The doc for --aggressive says nothing about repack, only that it
> optimizes harder.)

See above: the description of aggressiveWindow setting quite clearly
says that --aggressive does run repack.  And in fact it does, indeed.

> > Stephen can now be pissed off by himself.
> 
> Yup.  And I won't waste time on suppressing my irritation while
> helping with GitForEmacsDevs

Too bad.