Re: [PATCH] clone: in protocol v2, use remote's default branch

[Jeff King <peff@peff.net>]

On Tue, Dec 15, 2020 at 02:41:38AM +0100, Ævar Arnfjörð Bjarmason wrote:

> > > Another reason I'm not a fan of it is because it's another piece of
> > > magic "clone" does that you can't emulate in "init/fetch".
> > 
> > That ship has sailed longlonglong time ago when dfeff66e (revamp
> > git-clone., 2006-03-20) started pointing our HEAD to match theirs.
> 
> Let me rephrase: I think it's unfortunate when we add new things things
> to porcelain commands that aren't easy or possible to emulate in
> plumbing.
> 
> I.e. this feature seems like a candidate to be exposed by something like
> by a ls-remote flag if you'd like to do an init/config/fetch. AFAIK the
> only way to do it is to mock a "clone" with GIT_TRACE_PACKET or get the
> information out-of-bounds.

I think the situation is better than that. We are surfacing the remote
HEAD here, and there is already a command for copying that to our local
tracking symref: "git remote set-head origin -a", which will set up
refs/remotes/origin/HEAD.

I think there are two ways we could improve that further:

  - making it more natural to pick up or update the remote HEAD via
    fetch; Felipe's patches to git-fetch look good to me

  - it might be nice to be able to have some equivalent to the dwim "git
    checkout foo" that creates a new "foo" based off of origin/foo.
    Doing "git checkout origin/HEAD" will detach the HEAD. I think right
    now you'd have to do something like:

      tracking=$(git symbolic-ref refs/remotes/origin/HEAD)
      branch=${tracking#refs/remotes/origin/}
      git checkout -b $branch $tracking

    Or maybe not. It's not something people probably need to do a lot.
    And if the point is to have plumbing commands that can do the same,
    then maybe those commands are sufficient.

-Peff