Re: [PATCH v3 2/5] clone: add a --no-tags option to clone without tags

On Thu, Apr 27, 2017 at 7:54 PM, Stefan Beller [off-list ref] wrote:

On Wed, Apr 26, 2017 at 4:12 PM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:

quoted

Add a --no-tags option to clone without fetching any tags.

Without this change there's no easy way to clone a repository without
also fetching its tags.

When supplying --single-branch the primary remote branch will be
cloned, but in addition tags will be followed & retrieved. Now
--no-tags can be added --single-branch to clone a repository without
tags, and which only tracks a single upstream branch.

This option works without --single-branch as well, and will do a
normal clone but not fetch any tags.

Many git commands pay some fixed overhead as a function of the number
of references. E.g. creating ~40k tags in linux.git will cause a
command like `git log -1 >/dev/null` to run in over a second instead
of in a matter of milliseconds, in addition numerous other things will
slow down, e.g. "git log <TAB>" with the bash completion will slowly
show ~40k references instead of 1.

The user might want to avoid all of that overhead to simply use a
repository like that to browse the "master" branch, or something like
a CI tool might want to keep that one branch up-to-date without caring
about any other references.

Without this change the only way of accomplishing this was either by
manually tweaking the config in a fresh repository:

    git init git &&
    cat >git/.git/config <<EOF &&
    [remote "origin"]
        url = git@github.com:git/git.git
        tagOpt = --no-tags
        fetch = +refs/heads/master:refs/remotes/origin/master
    [branch "master"]
        remote = origin
        merge = refs/heads/master
    EOF
    cd git &&
    git pull

Which requires hardcoding the "master" name, which may not be the main
--single-branch would have retrieved, or alternatively by setting
tagOpt=--no-tags right after cloning & deleting any existing tags:

    git clone --single-branch git@github.com:git/git.git &&
    cd git &&
    git config remote.origin.tagOpt --no-tags &&
    git tag -l | xargs git tag -d

Which of course was also subtly buggy if --branch was pointed at a
tag, leaving the user in a detached head:

    git clone --single-branch --branch v2.12.0 git@github.com:git/git.git &&
    cd git &&
    git config remote.origin.tagOpt --no-tags &&
    git tag -l | xargs git tag -d

Now all this complexity becomes the much simpler:

    git clone --single-branch --no-tags git@github.com:git/git.git

Or in the case of cloning a single tag "branch":

    git clone --single-branch --branch v2.12.0 --no-tags git@github.com:git/git.git

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>

I like the option, though I dislike the implementation, specifically as you
brought up e.g. "[PATCH] various: disallow --no-no-OPT for --no-opt options".

Can we have an option "--tags" instead, which is on by default
and then you can negate it to --no-tags, without having to worry
about the no-no case.

The problem with tags is that they are in a shared name-space
and not part of the remote refspec. If they were, the documentation
would be way easier, too going this way.

I don't mind doing it this way, but this really should be part of an
unrelated topic to eliminate --no-OPT in favor of just --OPT which is
supplied by default, if we want to go that route.

Right now it makes more sense to have a --no-tags, because this along
with e.g. --no-hardlinks and numerous other options[1] is for an
obscure use-case most users won't care about, and then we have &
document --no-BEHAVIOR.

Perhaps we shouldn't have that at all, go through all these --no-OPT
and replace them with --OPT in both the docs & code & get rid of the
--no-no-OPT & some confusion that way.

1. git grep -- '\[--no-' Documentation/git-*txt

quoted

+--no-tags::
+       Don't clone any tags, and set
+       `remote.<remote>.tagOpt=--no-tags` in the config, ensuring
+       that future `git pull` and `git fetch` operations won't follow
+       any tags. Subsequent explicit tag fetches will still work,
+       (see linkgit:git-fetch[1]).
++
+Can be used in conjunction with `--single-branch` to clone and
+maintain a branch with no references other than a single cloned
+branch. This is useful e.g. to maintain minimal clones of the default
+branch of some repository for search indexing.

In the future we may want to have '--depth' also imply --no-tags,
just as it implies --single-branch.

Are there some cases where we'd like to also somehow import & rewrite
tags covering the given --depth?

quoted

@@ -652,7 +655,7 @@ static void update_remote_refs(const struct ref *refs,

        if (refs) {
                write_remote_refs(mapped_refs);
-               if (option_single_branch)
+               if (option_single_branch && !option_no_tags)

I am debating if this needs to be an || instead of &&, as you would not
want to write the tags with "--no-single-branch --no-tags" ?

This hunk is confusing out of context, but I believe it's doing the
right thing now. This write_followtags() codepath is only taken (and
is only meaningful) with --single-branch, there's an earlier change
just before that:

    -       if (!option_mirror && !option_single_branch)
    +       if (!option_mirror && !option_single_branch && !option_no_tags)
                    get_fetch_map(refs, tag_refspec, &tail, 0);

Which ensures that with --no-single-branch --no-tags that tags aren't
written, and there's tests for that.