On Mon, Dec 14 2020, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>> Maybe not for reasons I haven't thought of, but I'd at least be much
>> happier with an updated commit message justifying another special-case
>> in clone that you can't do with "init/fetch".
>
> This is *not* another special-case, but is 14-year old outstanding
> one, so I do not think there specifically needs such justification.
> The log message DOES need to be clarified. Your mistaking that this
> is a new feature and not a bugfix may be a good indication that the
> proposed log message is not doing its job.
For context: This clone feature has been there since early 2009, it
wasn't until late 2017/early 2018 that we had protocol v2 that gave us
the ability to fix the bug.
I suppose the distinction between what's new behavior and what's a
bugfix in something that was really meant to work a certain way all
along but didn't is too subtle for me to discern sometimes :)
86ac7518590 (Allow cloning an empty repository, 2009-01-23) which added
it seems to match my mental model of it being just a shortcut for some
of the the URL config "init" otherwise wouldn't setup for you. At a time
when git-init.txt said:
An initial `HEAD` file that references the HEAD of the master branch
is also created.
> > 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.
>> And on the "litte gain" side of things: I very much suspect that the
>> only users who'll ever use this will be some big hosting providers (but
>> maybe not, the commit doesn't suggest a use-case).
>
> Explorers who learn this new GitHub or GitLab thingy, create an
> empty repository there and then clone it to their local disk, just
> to dip their toes in the water, would most benefit. Those of us who
> are working on an already existing and populated projects won't be
> helped or bothered. We do sometimes create our own repositories and
> publish to hosting sites, and I expect that many experienced Git
> users follow the "local first and the push", and they won't be
> helped or bothered.
>
> But I expect some do "create a void at the hosting site and clone to
> get a local playpen" for their real projects. They would be helped,
> and because Git userbase is populous enough that their number in
> absolute terms would not be insignificant, even if they weren't in
> percentage terms.
That's how I've always used it. Seems from the above-referenced
5cd12b85fe8 that's what it was meant for to begin with.
Anyway, there's 3 replies to my E-Mail including yours insisting this
makes perfect sense, I'm happy to go along with the consensus. I wrote
my reply with the assumption that it was obvious that this was a change
in established behavior, but apparently that's not the prevailing view.
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 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...).
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?
But of course then when you push your "foobar" as the first branch the
HEAD symref won't be updated. In the olden times when everyone ran their
own git server this was a common FAQ, "just run 'git symbolic-ref'".
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.
