Re: not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main

["Kristoffer Haugsbakk" <code@khaugsbakk.name>]

Hi

On Tue, May 30, 2023, at 20:14, Carlos wrote:
> Running git 2.40.1 with HEAD -> master, origin/main, origin/HEAD,
> origin/master, main with initial commit on main does not show all the
> objects from master

Does this mean that `HEAD` and all of these other things point to the
same commit? Is this the output of `git log` with decorations?

What are `main` and `master` meant to represent? One often doesn’t use
both of these names unless you have a legacy setup (originally `master`,
then moved to `main`).

What can be confusing to me is that git(1) uses `master` as the default
branch name that you get after `git init`—this can be configured, but
`master` is currently the default.[1] Meanwhile, GitHub uses `main` as
the default name. So what sometimes happens:

1. Someone makes a local repository with `master` as the initial branch
2. They make a repository on GitHub
3. They click on “add a readme” or something
4. Then GitHub creates a branch `main` with that readme addition on it
5. They push their local changes and end up with two “default” branches:
   `master` with their own changes, and `main` with the default readme

Maybe both you (locally) and GitHub made commits named “Initial commit”?

† 1: I’ve heard that the default might be `main` on Git For Windows, though?

> ! [main] Initial commit
>  * [master] Initial commit
>   ! [origin/master] Initial commit
> ---
> +*+ [main] Initial commit
>
> the chunk of objects are on master and not main, and yet it shows
> nothing once checking out to master.

It looks like both `master` and `main` point to the same commit.

Do you have some command that you expected X output or behavior from,
but instead got Y output or behavior?

> the git-clone operation is not consistent either. It's a disaster.

What do you expect it to do and what actually happens?

Cheers

-- 
Kristoffer Haugsbakk