[Discuss] soften warning message after cloning "void"

If you did this:

    $ git init void &&
      git -C void commit --allow-empty -m initial &&
      git -C void symbolic-ref HEAD refs/heads/nosuch
    $ git clone --no-local void new

you would get

    warning: remote HEAD refers to nonexistent ref, unable to checkout.

While it is correct that we are unable to perform the normal "checkout" of their primary branch that their HEAD points at, it was reported that some users find this message unnecessarily alarming.

Rephrase by saying what we decided to do, instead of only stating what led us to that decision without telling what that decision is. That is, "(because we cannot checkout), we left the HEAD pointing at an unborn branch."

---
 builtin/clone.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

On Wed, Feb 18, 2015 at 3:24 PM, Junio C Hamano <gitster@pobox.com> wrote:

I think there is another problem. $ git status On branch master

Initial commit

which makes no sense.

So after playing around I found:

$ git init void &&
   git -C void commit --allow-empty -m initial &&
   touch void/asdf
   git -C void add asdf
   git -C void commit -a -m "add a file"
   git -C void symbolic-ref HEAD refs/heads/nosuch
   git clone --no-local void new

This yields the warning as above and git status still tells us we're on master. Though ls new shows an empty directory/repository. After a `git checkout master` we can see the file and all is good to go.

How did we know we are on the master branch in the first place? (and not on foo/bar, HEAD is pointing at nonsense!) So what is the `current branch` of your new error message referring to?

Why did git status claim to be on branch master, but the repository state was not in masters state, but in the unborn state?

These questions asked, would it make sense to either add a git checkout `current branch` at the end of clone? (I suppose that is what HEAD is good for actually).

Also it would make sense to have it's own HEAD pointing to 0{40} or equivalent (just nothing) instead of having the master branch available.

Personally I find that more confusing, because I have an idea of what checkout may refer to. The notion of an unborn branch is not clear to me. Maybe

with $branch being master in the example above. I'd have no idea how to come up with a good heuristic which branch to checkout. (It would need to match current behavior)

On Wed, Feb 18, 2015 at 4:13 PM, Stefan Beller <sbeller@google.com> wrote:

Checking out a random branch is absolutely the worst thing you can do. Personally, I would think that the best thing you can do is to educate your users not to clone from a void. Create some history that is worth sharing, and then push into an empty repository.

On Wed, Feb 18, 2015 at 4:25 PM, Junio C Hamano <gitster@pobox.com> wrote:

Users are dumb.

Consider a website like GitHub where you create a repository on a a remote server. It is initialized as an empty repo. They now want to clone that empty repo to work with it:

  git clone https://example.com/foo
  cd foo
  .... hack hack
  git commit -a -m "Foo is awesome!"
  git push

This works from git-core servers because the ref advertisement tells the client its an empty repo and its OK to checkout HEAD from nothing and its all fine.

This fails from a JGit server because the ref advertisement for an empty repository differs and disagrees with the format used by git-core. The result is a confused client spewing an odd checkout message.

On Wed, Feb 18, 2015 at 4:43 PM, Shawn Pearce <spearce@spearce.org> wrote:

The difference in JGit is intentional. Our cross data center consistency system at $DAY_JOB depends on being able to fetch from one empty repository to another empty repository using the want any object capability, and side-band-64k. The JGit client and server code that speaks the wire protocol needs to send and see the capability lines for that to work, but with no refs there are no lines to send.

So we send capabilities^{} like receive-pack does. But git-core hates all over that during clone of an empty repo.

On Wed, Feb 18, 2015 at 4:43 PM, Shawn Pearce <spearce@spearce.org> wrote:

That is exactly why the rephrasing was brought up, wasn't it?

As the Subject: line says, this thread is for people who want to help those users with un-odd message, so discuss away and come up with a final applicable patch ;-).

On Wed, Feb 18, 2015 at 6:54 PM, Junio C Hamano <gitster@pobox.com> wrote:

"warning: remote HEAD does not exist, not checking out any branch."

would then be the correct answer. Are we able to detect between the two cases of a HEAD pointing to refs/heads/void and HEAD just not existing?

Stefan Beller <sbeller@google.com> writes:

Technically speaking, that is incorrect because HEAD already points at 'master'. We DO check out a 'master' branch. What is unusual is that the branch has not been born yet, and that is exactly the same state after 'git init' created an empty directory. I.e.

	$ git init new
        $ cd new
        $ git remote add origin $URL
	$ git symbolic-ref HEAD
        refs/heads/master

would be exactly the same place where you are when you see that message.

What we are not doing is not "not checking out". What we are not doing is to fast-forwarding the void to any of the branches the remote has, because we do not know which branch the remote wants us to start our history from by default.

So, "warning: not starting history of 'master' from any of the remote's branches, as their HEAD does not point to a valid branch" or something like that?

On Wed, Feb 18, 2015 at 4:25 PM, Junio C Hamano <gitster@pobox.com> wrote:

I agree on that, but why did I see the master branch checked out? (There was just one branch, so it's obvious which to checkout instead) But HEAD being broken, I would have expected

$ git clone ... remote HEAD refers to nonexistent ref, checking out nothing $ git status HEAD detached at (nothing)

I disagree on that. The repository may be broken by tinkering (why would you run git -C void symbolic-ref HEAD refs/heads/nosuch anywazy?) and people want to clone it nevertheless.

I am not sure what you mean here.