Re: [PATCH] clone: teach --single-branch and --branch during --recurse

From: Jeff King <peff@peff.net>
Date: Jan 28, 2020, 01:31 UTC
Message-ID: <20200128013139.GA38223@coredump.intra.peff.net>
In-Reply-To: <20200128010841.GD233139@google.com>

On Mon, Jan 27, 2020 at 05:08:41PM -0800, Emily Shaffer wrote:

Show 10 quoted lines

> > Yeah, I do still think that it makes sense for clone to pass along
> > --single-branch, regardless, and then deal with branch selection problem
> > separately on top.
> 
> Sure; I've got that ready to send shortly. It seems to grab HEAD of the
> remote for each submodule, and then checkout the specific commit ID the
> superproject wants - in my test case, that commit ID was a direct
> ancestor of 'master', so the single branch only got 'master'. I'm not
> sure how it would work with a commit ID which doesn't exist in the
> single branch that was fetched; I'll write a test and have a look.

Yeah, it's definitely worth exploring how that works. I thought we had some kind of fallback for when we didn't manage to fetch the object. But maybe I am confusing it with the fallback for "we tried to fetch this specific object, but the other side doesn't allow that, so we grabbed a branch instead".

Show 5 quoted lines

> > So for the simple case, you probably do want to be able to say "use this
> > branch for cloning all submodules".
> 
> I think it still makes sense to call this out explicitly, yes? Or do you
> think that should just be the default?

Yes, I think it should be a separate option from "--branch".

Show 16 quoted lines

> This made me think - I wonder if it makes sense to take
> --submodule-branch as a wildcarded spec instead. So in your case, I
> could say,
> 
>   git clone --submodule-branch *=devel -b devel superproject
> 
> And then I don't need to do anything differently for 'git fetch' later.
> This also opens the door for some repos getting special treatment:
> 
>   git clone --submodule-branch-file=foo.txt -b dev example
> 
>   foo.txt:
>   curl=stable-1.2.3
>   nlohmann=v2.28
>   example-*=dev
>   *=master

If we write it all as config, I think things may get simpler. IIRC, there is already submodule.*.foo config in .git/config (that can mirror and override what's in .gitmodules).

So if we had some config option for "clone this branch for the submodule instead of HEAD", then that means you can do:

  git clone -c submodule.foo.clonehead=devel ...

and the result would be used by the submodule code, but also saved for future invocations. Likewise, if there's no "clonehead" config for a particular submodule, if we fall back to submodule.defaultclonehead, then you could do:

  git clone -c submodule.defaultclonehead=devel ...

and it would also be saved as the default for future submodules. And all without having to invent a new submodule-branch-file format.

The name "clonehead" isn't great. I'm not sure if this ought to be submodule.*.branch (since I don't quite know what that's used for). I think you'll have to explore that a bit.

Show 7 quoted lines

> I think that also tends to match the glob-expansion configs we use for
> other things. One thing sticking out to me about the idea of providing
> --submodule-branch is that you need to know what's in the repo before
> you clone it the first time, which being able to use globbing like this
> kind of helps with. But then, I suppose if you don't know what you're
> looking for, you're not also looking for a very precise filter on your
> clone ;)

Yeah; the scheme I outlined above only allow specifying the value for one submodule, or the fallback default. It wouldn't allow arbitrary globbing. But I also suspect nobody wants that. If you know what the submodules are, then you can set up config for each. If you don't, then "everything" is the only glob that makes sense.

-Peff