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

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> 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.

Yes, I think the updated protocol should be able to help adding a
new feature usable by script writers, and I agree that ls-remote may
be the ideal home for such a feature.

> To borrow from Felipe Contreras's reply in the side-thread "I expect the
> branch name to be chosen by the person who created that repository".

I expect a bit differently.  My expectation is that "git clone"
tries to help you inter-operate well with the project you clone.
You may be creating your local repository by cloning theirs, but
because I do not expect "who created" matters more than how well
end-users' workflows would work in the resulting repository, I
do not expect local init.defaultBranch should matter here.

If the project you would eventually push back to designates one
branch as its primary branch everybody is expected to work off of
(which is what it means to point it with their HEAD), it is
convenient if your local clone names your primary branch to match.
The push.default settings like 'simple' and 'current' are designed
to work well when your local branch namespace matches what they
have.

> I suppose this comes down to a mental model of what it means to have
> "created a repository". When I click "create repo" on those popular
> hosting sites (e.g. github & gitlab) and clone it I was expecting it to
> just be a shorthand init + a URL in my config (and refspecs...).

So, no, I do not think "who created a repository" has much to do
with the objective of the patch in question.  It's really "what's
the upstream's view of the primary branch".

> That's also what happens with this patch if you "git init --bare
> /tmp/my.git", then edit the HEAD symref to point to "foobar" and clone
> it with file:///, it'll be "master" in your clone (or whatever
> init.defaultBranch is). Isn't that discrepancy a bug then?

Yes, I view it as the same bug to be fixed; JTan's protocol update
patch only deals with the transport based on the git protocol and
does not (yet?) address the --local short-cut.  In principle, it
should be a lot easier than the protocol update.  Any takers?

> On both of those big hosting sites (didn't test others) whatever their
> preferred default name is they'll go with your idea and update HEAD's
> pointer on the first such push. So this notion that the default unborn
> symref isn't transported & it's up to the client to set it on-push (or
> manually afterwards) has been reinforced by in-the-wild use.

I think it would be great if somebody comes up with a protocol
update for that "other" direction to push into an unborn HEAD.  I
haven't thought things through, but you may be right to point out
that the "clone learns and prepares local to match the other side"
we are discussing may not be complete with such a corresponding fix
in the opposite direction.

Thanks.