* not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main
@ 2023-05-30 17:58 Carlos
0 siblings, 0 replies; 7+ messages in thread
From: Carlos @ 2023-05-30 17:58 UTC (permalink / raw)
To: git
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
! [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.
the git-clone operation is not consistent either. It's a disaster.
One would think that by now with the more developed work put on to git, it'd
be safe to assume the more sense there's on newer versions. But no. This
is the opposite actually.
Now. If by any chance the git-branch operation were to return:
main
* master
after git-clone, then objects are indeed in place. That is. On master
but not if git-branch returns
main
* master
origin/master
--
Our documentation manager was showing her 2 year old son around the office.
He was introduced to me, at which time he pointed out that we were both
holding bags of popcorn. We were both holding bottles of juice. But only
*he* had a lollipop.
He asked his mother, "Why doesn't HE have a lollipop?"
Her reply: "He can have a lollipop any time he wants to. That's
what it means to be a programmer."
^ permalink raw reply [flat|nested] 7+ messages in thread
* not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main
@ 2023-05-30 18:14 Carlos
2023-05-31 10:08 ` Kristoffer Haugsbakk
2023-05-31 10:57 ` Philip Oakley
0 siblings, 2 replies; 7+ messages in thread
From: Carlos @ 2023-05-30 18:14 UTC (permalink / raw)
To: git
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
! [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.
the git-clone operation is not consistent either. It's a disaster.
One would think that by now with the more developed work put on to git, it'd
be safe to assume the more sense there's on newer versions. But no. This
is the opposite actually.
Now. If by any chance the git-branch operation were to return:
main
* master
after git-clone, then objects are indeed in place. That is. On master
but not if git-branch returns
main
* master
origin/master
--
This login session: $13.99
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main
2023-05-30 18:14 Carlos
@ 2023-05-31 10:08 ` Kristoffer Haugsbakk
2023-05-31 10:57 ` Philip Oakley
1 sibling, 0 replies; 7+ messages in thread
From: Kristoffer Haugsbakk @ 2023-05-31 10:08 UTC (permalink / raw)
To: Carlos; +Cc: git
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main
2023-05-30 18:14 Carlos
2023-05-31 10:08 ` Kristoffer Haugsbakk
@ 2023-05-31 10:57 ` Philip Oakley
2023-05-31 13:22 ` Philip Oakley
1 sibling, 1 reply; 7+ messages in thread
From: Philip Oakley @ 2023-05-31 10:57 UTC (permalink / raw)
To: Carlos, git
On 30/05/2023 19: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
>
>
> ! [main] Initial commit
> * [master] Initial commit
> ! [origin/master] Initial commit
> ---
> +*+ [main] Initial commit
>
this is the output of `git show-branch` [1] which has its own special
display format. It's not often used these days.
The `!` are column markers, as is `*` for the current branch.
You have three branches listed
Then you have the `---` divider
Finally you has the single commit, showing which branches the commit is
'on'.
Be careful to discriminate between being 'on' a branch (at it's tip, by
name); 'at' an oid (object id / hash); and `in` a branch (below its
tip); etc.
[1] https://git-scm.com/docs/git-show-branch
> the chunk of objects are on master and not main, and yet it shows
> nothing once checking out to master.
>
> the git-clone operation is not consistent either. It's a disaster.
>
> One would think that by now with the more developed work put on to git, it'd
> be safe to assume the more sense there's on newer versions. But no. This
> is the opposite actually.
>
> Now. If by any chance the git-branch operation were to return:
>
> main
> * master
>
> after git-clone, then objects are indeed in place. That is. On master
>
> but not if git-branch returns
>
> main
> * master
> origin/master
>
>
>
Philip
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main
2023-05-31 10:57 ` Philip Oakley
@ 2023-05-31 13:22 ` Philip Oakley
2023-05-31 21:35 ` Carlos
0 siblings, 1 reply; 7+ messages in thread
From: Philip Oakley @ 2023-05-31 13:22 UTC (permalink / raw)
To: Carlos, git
On 31/05/2023 11:57, Philip Oakley wrote:
> On 30/05/2023 19: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
>>
>>
>> ! [main] Initial commit
>> * [master] Initial commit
>> ! [origin/master] Initial commit
>> ---
>> +*+ [main] Initial commit
>>
>
> this is the output of `git show-branch` [1] which has its own special
> display format. It's not often used these days.
>
> The `!` are column markers, as is `*` for the current branch.
> You have three branches listed
> Then you have the `---` divider
>
> Finally you has the single commit, showing which branches the commit is
> 'on'.
>
> Be careful to discriminate between being 'on' a branch (at it's tip, by
> name); 'at' an oid (object id / hash); and `in` a branch (below its
> tip); etc.
>
>
> [1] https://git-scm.com/docs/git-show-branch
>
>> the chunk of objects are on master and not main, and yet it shows
>> nothing once checking out to master.
>>
>> the git-clone operation is not consistent either. It's a disaster.
>>
>> One would think that by now with the more developed work put on to git, it'd
>> be safe to assume the more sense there's on newer versions. But no. This
>> is the opposite actually.
>>
>> Now. If by any chance the git-branch operation were to return:
>>
>> main
>> * master
>>
>> after git-clone, then objects are indeed in place. That is. On master
>>
>> but not if git-branch returns
>>
>> main
>> * master
>> origin/master
>>
You may have accidentally created a local branch called `origin/master`
which you are now confusing with the (unlisted) remote tracking branches.
What does
git branch -ra
produce?
It will show the local branches first, and then your
`remotes/repo/branches` list (probably colourised).
This should help confirm what you have.
>>
>>
> Philip
P.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main
2023-05-31 13:22 ` Philip Oakley
@ 2023-05-31 21:35 ` Carlos
2023-05-31 22:36 ` Carlos
0 siblings, 1 reply; 7+ messages in thread
From: Carlos @ 2023-05-31 21:35 UTC (permalink / raw)
To: git
On Wed, May 31, 2023 at 02:22:59PM +0100, Philip Oakley wrote:
> On 31/05/2023 11:57, Philip Oakley wrote:
> > On 30/05/2023 19: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
> >>
> >>
> >> ! [main] Initial commit
> >> * [master] Initial commit
> >> ! [origin/master] Initial commit
> >> ---
> >> +*+ [main] Initial commit
> >>
> >
> > this is the output of `git show-branch` [1] which has its own special
> > display format. It's not often used these days.
> >
> > The `!` are column markers, as is `*` for the current branch.
> > You have three branches listed
> > Then you have the `---` divider
> >
> > Finally you has the single commit, showing which branches the commit is
> > 'on'.
> >
> > Be careful to discriminate between being 'on' a branch (at it's tip, by
> > name); 'at' an oid (object id / hash); and `in` a branch (below its
> > tip); etc.
> >
> >
> > [1] https://git-scm.com/docs/git-show-branch
> >
> >> the chunk of objects are on master and not main, and yet it shows
> >> nothing once checking out to master.
> >>
> >> the git-clone operation is not consistent either. It's a disaster.
> >>
> >> One would think that by now with the more developed work put on to git, it'd
> >> be safe to assume the more sense there's on newer versions. But no. This
> >> is the opposite actually.
> >>
> >> Now. If by any chance the git-branch operation were to return:
> >>
> >> main
> >> * master
> >>
> >> after git-clone, then objects are indeed in place. That is. On master
> >>
> >> but not if git-branch returns
> >>
> >> main
> >> * master
> >> origin/master
> >>
>
> You may have accidentally created a local branch called `origin/master`
> which you are now confusing with the (unlisted) remote tracking branches.
>
if the remotes are in place,
main
* master
origin/master
remotes/origin/HEAD -> origin/main
remotes/origin/main
remotes/origin/master
what exactly is origin/master doing there? even by assuming I created it
(which I didn't but let's say I did) then:
git checkout origin/master
warning: refname 'origin/master' is ambiguous.
Switched to branch 'origin/master'
confirms it that given the above, it follows that `git checkout
origin/master` would fail to create and to be in quote in 'detached
HEAD' state. To look around, make experimental changes and commit them,
and to discard any commits one makes in this state without impacting
any branches by switching back to a branch` . blah blah blah
as does the one without the origin/master , right?
Now, if I were to do the same under the worktree (the tree holding the
contents correctly on both main and master, right?) with git branch -ra:
main
* master
remotes/origin/HEAD -> origin/main
remotes/origin/main
remotes/origin/master
which behaves accordingly
* (HEAD detached at origin/master)
main
master
remotes/origin/HEAD -> origin/main
remotes/origin/main
remotes/origin/master
> What does
>
> git branch -ra
>
> produce?
>
> It will show the local branches first, and then your
> `remotes/repo/branches` list (probably colourised).
>
> This should help confirm what you have.
> >>
> >>
> > Philip
> P.
>
--
Modeling paged and segmented memories is tricky business.
-- P. J. Denning
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main
2023-05-31 21:35 ` Carlos
@ 2023-05-31 22:36 ` Carlos
0 siblings, 0 replies; 7+ messages in thread
From: Carlos @ 2023-05-31 22:36 UTC (permalink / raw)
To: git
On Wed, May 31, 2023 at 05:35:58PM -0400, Carlos wrote:
> On Wed, May 31, 2023 at 02:22:59PM +0100, Philip Oakley wrote:
> > On 31/05/2023 11:57, Philip Oakley wrote:
> > > On 30/05/2023 19: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
> > >>
> > >>
> > >> ! [main] Initial commit
> > >> * [master] Initial commit
> > >> ! [origin/master] Initial commit
> > >> ---
> > >> +*+ [main] Initial commit
> > >>
> > >
> > > this is the output of `git show-branch` [1] which has its own special
> > > display format. It's not often used these days.
> > >
> > > The `!` are column markers, as is `*` for the current branch.
> > > You have three branches listed
> > > Then you have the `---` divider
> > >
> > > Finally you has the single commit, showing which branches the commit is
> > > 'on'.
> > >
> > > Be careful to discriminate between being 'on' a branch (at it's tip, by
> > > name); 'at' an oid (object id / hash); and `in` a branch (below its
> > > tip); etc.
> > >
> > >
> > > [1] https://git-scm.com/docs/git-show-branch
> > >
> > >> the chunk of objects are on master and not main, and yet it shows
> > >> nothing once checking out to master.
> > >>
> > >> the git-clone operation is not consistent either. It's a disaster.
> > >>
> > >> One would think that by now with the more developed work put on to git, it'd
> > >> be safe to assume the more sense there's on newer versions. But no. This
> > >> is the opposite actually.
> > >>
> > >> Now. If by any chance the git-branch operation were to return:
> > >>
> > >> main
> > >> * master
> > >>
> > >> after git-clone, then objects are indeed in place. That is. On master
> > >>
> > >> but not if git-branch returns
> > >>
> > >> main
> > >> * master
> > >> origin/master
> > >>
> >
> > You may have accidentally created a local branch called `origin/master`
> > which you are now confusing with the (unlisted) remote tracking branches.
> >
>
> if the remotes are in place,
>
> main
> * master
> origin/master
> remotes/origin/HEAD -> origin/main
> remotes/origin/main
> remotes/origin/master
>
>
> what exactly is origin/master doing there? even by assuming I created it
> (which I didn't but let's say I did) then:
>
> git checkout origin/master
>
> warning: refname 'origin/master' is ambiguous.
> Switched to branch 'origin/master'
>
> confirms it that given the above, it follows that `git checkout
> origin/master` would fail to create and to be in quote in 'detached
> HEAD' state. To look around, make experimental changes and commit them,
> and to discard any commits one makes in this state without impacting
> any branches by switching back to a branch` . blah blah blah
>
> as does the one without the origin/master , right?
>
Fe de errata:
*unlike the one without the origin/master, which *successfully* does,
as shown below:
> Now, if I were to do the same under the worktree (the tree holding the
> contents correctly on both main and master, right?) with git branch -ra:
>
>
> main
> * master
> remotes/origin/HEAD -> origin/main
> remotes/origin/main
> remotes/origin/master
>
> which behaves accordingly
>
> * (HEAD detached at origin/master)
> main
> master
> remotes/origin/HEAD -> origin/main
> remotes/origin/main
> remotes/origin/master
>
>
> > What does
> >
> > git branch -ra
> >
> > produce?
> >
> > It will show the local branches first, and then your
> > `remotes/repo/branches` list (probably colourised).
> >
> > This should help confirm what you have.
> > >>
> > >>
> > > Philip
> > P.
> >
>
> --
> Modeling paged and segmented memories is tricky business.
> -- P. J. Denning
>
>
--
Put no trust in cryptic comments.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-05-31 22:37 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-30 17:58 not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main Carlos
-- strict thread matches above, loose matches on Subject: below --
2023-05-30 18:14 Carlos
2023-05-31 10:08 ` Kristoffer Haugsbakk
2023-05-31 10:57 ` Philip Oakley
2023-05-31 13:22 ` Philip Oakley
2023-05-31 21:35 ` Carlos
2023-05-31 22:36 ` Carlos
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).