New repo issues?

[Rod]

I'm having trouble setting up and then cloning a new repo on my gitolite server.

The same steps work on Github so I wonder is this is Gitolite?

Apologies in advance if this is all my brainfart.

Ultimately this results in:

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

I wonder is it has to do with me using "main" and not "master"?

# On the server...

$ bin/gitolite compile; bin/gitolite trigger POST_COMPILE

Initialized empty Git repository in /home/git/repositories/foobar.git/

# On the client

$ git init .

Initialized empty Git repository in /Users/XXX/foobar/.git/

$ git add .

$ git commit -m "First check-in"

[main (root-commit) 90908ba] First check-in

5 files changed, 285 insertions(+)

create mode 100644 file1

create mode 100644 file2

create mode 100644 file3

create mode 100755 file4

create mode 100644 file5

$ git remote add origin g...@xxxxx.com:foobar.git

$ git push -u origin main

Enumerating objects: 8, done.

Counting objects: 100% (8/8), done.

Delta compression using up to 8 threads

Compressing objects: 100% (7/7), done.

Writing objects: 100% (8/8), 4.17 KiB | 4.17 MiB/s, done.

Total 8 (delta 0), reused 0 (delta 0), pack-reused 0

To xxxxx.com:foobar.git

* [new branch]      main -> main

Branch 'main' set up to track remote branch 'main' from 'origin'.

# cd to a new folder

$ git clone git@xxxxx:foobar.git

Cloning into 'foobar'...

remote: Enumerating objects: 8, done.

remote: Counting objects: 100% (8/8), done.

remote: Compressing objects: 100% (7/7), done.

remote: Total 8 (delta 0), reused 0 (delta 0)

Receiving objects: 100% (8/8), 4.17 KiB | 4.17 MiB/s, done.

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

# No files are pulled down

# If I do this, I get

$ git branch --set-upstream-to=origin/main main

fatal: branch 'main' does not exist

Thanks, Rod

[Nick]

January 16, 2022 4:07 PM, "Rod" <r...@cabdar.com> wrote:

> Apologies in advance if this is all my brainfart.
>

> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
> I wonder is it has to do with me using "main" and not "master"?
>

Don't worry it's not a brainfart! It's because gitolite doesn't support the new init.defaultBranch setting, exactly what you guessed


I ran into this too: https://groups.google.com/g/gitolite/c/NwZ1-hq9-9E/m/mDbiKyAvDwAJ

The workaround is:

1. enable `symbolic-ref` in ~/.gitolite.rc: https://gitolite.com/gitolite/cookbook.html#making-commands-available-to-remote-users

2. `ssh git@server symbolic-ref my/repo HEAD refs/heads/main`

You can also fix it for *all* repos if you log in *on the server* and match init.defaultBranch to your client:

```
ssh ro...@server.example.com
su -l git # important! you have to log in as root and then switch to git; because otherwise you go through gitolite
git config --global init.defaultBranch main
```

GitHub and GitLab seem to be able to detect the first branch pushed, and they use that. You can test this by make a test repo but making sure to ignore GitHub's advice to push to `master`:

$ mkdir test1
$ cd test1
$ git init
Initialized empty Git repository in /home/kousu/src/test1/.git/
$ git checkout -b branch-apples
Switched to a new branch 'branch-apples'
$ touch README
$ git add README && git commit -m "Initial commit"
[branch-apples (root-commit) 728a27d] Initial commit
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README
$ gitgit remote add origin g...@github.com:kousu/apples1.git^C
$ git remote add origin g...@github.com:kousu/apples1.git
$ git push -u origin branch-apples
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 201 bytes | 201.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:kousu/apples1.git
* [new branch] branch-apples -> branch-apples
Branch 'branch-apples' set up to track remote branch 'branch-apples' from 'origin'.
$ # then look in https://github.com/kousu/apples1/settings/branches; it says
$ # >
$ # > Default branch
$ # > The default branch is considered the “base” branch in your repository, against which all pull requests and code commits are automatically made, unless you specify a different branch.
# > `branch-apples`


Gitlite doesn't have this feature -- it just assumes runs `git init` which uses `init.defaultBranch` on the server side, instead of looking at what's being pushed to it. Would you be interested in working up a patch for this with me?

-Nick

[Rod]

>> Apologies in advance if this is all my brainfart.
>>
>> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>>
>> I wonder is it has to do with me using "main" and not "master"?
>>
>
> Don't worry it's not a brainfart! It's because gitolite doesn't support
> the new init.defaultBranch setting, exactly what you guessed
>

Using "ssh git@server symbolic-ref myrepo.git HEAD refs/heads/main" on the clients works great. Setting init.defaultBranch on the server doesn't seem to do anything.

My short term problem is solved but having to do symbolic-ref on any new repo is a little cumbersome.

I would be interested in helping with a patch, but my perl skills are quite limited. The first website I ever built in 1998 was in Perl and then nothing since.

Rod

> --
> You received this message because you are subscribed to the Google
> Groups "gitolite" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to gitolite+u...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gitolite/d49fd9b2e74af1a5ec6d98e752baa007%40kousu.ca.

[Sitaram Chamarty]

On Sat, Jan 22, 2022 at 07:15:22AM -0800, Rod wrote:
> >> Apologies in advance if this is all my brainfart.
> >>
> >> warning: remote HEAD refers to nonexistent ref, unable to checkout.
> >>
> >> I wonder is it has to do with me using "main" and not "master"?
> >>
> >
> > Don't worry it's not a brainfart! It's because gitolite doesn't support
> > the new init.defaultBranch setting, exactly what you guessed
> >
>

> Using "ssh git@server symbolic-ref myrepo.git HEAD refs/heads/main" on the clients works great. Setting init.defaultBranch on the server doesn't seem to do anything.
>
> My short term problem is solved but having to do symbolic-ref on any new repo is a little cumbersome.
>
> I would be interested in helping with a patch, but my perl skills are quite limited. The first website I ever built in 1998 was in Perl and then nothing since.

You don't need perl to add such functionality.

If you look at the link to the older discussion that Nick gave
in his earlier response, you will see a suggested method using a
POST_GIT trigger and it's written in bash.

I'm not sure if Nick tried that back about a year ago when that
thread happend; I don't recall. I had miniimally tested it of
couurse.

You could test that out, and if it works, you can make it more
efficient by adding something like this after the "cd ..." on
line 5:

[[ -f gl-symbolic-ref-post-git.done ]] && exit
touch gl-symbolic-ref-post-git.done

This takes advantage of the fact that git doesn't care what
*other* files are present in its ".git" (or directly in a bare
repo). Gitolite itself uses this trick a few places, especially
the gl-conf file, and other "gl-*" files for other purposes.

hope this helps
sitaram

> To view this discussion on the web visit https://groups.google.com/d/msgid/gitolite/eae69122-bc6d-42cd-bee3-6b82fda14a4b%40www.fastmail.com.

[Sitaram Chamarty]

On Sun, Jan 23, 2022 at 11:35:13AM +0530, Sitaram Chamarty wrote:

> You don't need perl to add such functionality.

Just to be clear, the *only* parts of non-core gitolite that
need perl are:

- INPUT triggers (the other 6 kinds of triggers can be in any
language)
- syntactic sugar helpers

for some types of triggers, it may be more *efficient* to have
them in perl but it's not *required*.

I guess this was not explicitly documented; I'll try and do that
soon.

Needless to say, "core" gitolite is all perl, and I am much more
hesitant to make signifcant changes there unless there is a
really good reason

regards
sitaram