Cloning fails for repos using 'main' as the default branch name

[marcomicera]

Bug description

When omitting the branch name (GIT_SYNC_BRANCH/--branch), I would assume that the default branch would be synced.
The default branch name has been hardcoded as "master", but that's not always the case (junit uses "main", for instance).

MWE

Just cloning a repo and listing its content.

apiVersion: batch/v1
kind: Job
metadata:
  name: clone-main-branch
spec:
  backoffLimit: 1
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: lister
        image: alpine
        command: [ "sh", "-c", "ls /home/project" ]
        volumeMounts:
        - name: repo-volume
          mountPath: /home
      initContainers:
      - name: cloner
        image: k8s.gcr.io/git-sync/git-sync:v3.1.7
        env:
#          - name: GIT_SYNC_REPO
#            value: https://github.com/google/guava # Works. Default branch name: master.
          - name: GIT_SYNC_REPO
            value: http://github.com/junit-team/junit # Doesn't work. Default branch name: main.
          - name: GIT_SYNC_ROOT
            value: /home
          - name: GIT_SYNC_DEST
            value: project
          - name: GIT_SYNC_ONE_TIME
            value: "1"
          - name: GIT_SYNC_DEPTH
            value: "1"
          - name: GIT_SYNC_SUBMODULES
            value: "shallow"
        volumeMounts:
          - name: repo-volume
            mountPath: /home
      volumes:
      - name: repo-volume
        emptyDir: {}

Proposed solution

1. Set the default branch name to an empty string or nil.
2. Avoid using git's -b flag when the previous variable is empty/nil.

[thockin]

This is a reasonable change but could be breaking. If we're going to do this, let's do it in context of a v4 branch.

[stp-ip]

I agree that this is a breaking change and a bad one in terms of user impact. So v4 is needed I agree.

For context. Git itself (https://lore.kernel.org/git/xmqq4kp8903z.fsf@gitster.c.googlers.com/T/#t) hasn't finished their migration so there is still time until this will be breaking more users in both directions. So far one can set a branch and it works, so users with "main" as default branch already know how to circumvent the breaking.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[thockin]

/lifecycle frozen
/remove-lifecycle stale
/remove-lifecycle rotten

[thockin]

Fixed in v4 branch