{"thread":{"id":"59809","subject":"not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main","startedAt":"2023-05-30T18:30:23Z","lastAt":"2023-05-31T22:37:00Z","messageCount":6,"participants":["Carlos","Kristoffer Haugsbakk","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"477805","messageId":"lxh4jpacuv5ivqp35w5vpbcjlw67r7ix3yog6cc3cu5ij7yqho@mrtr24xxdstx","threadId":"59809","inReplyTo":null,"subject":"not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main","fromName":"Carlos","fromEmail":"kaploceh@gmail.com","sentAt":"2023-05-30T18:14:44Z","receivedAt":"2023-05-30T18:30:23Z","isPatch":false,"sender":{"key":"kaploceh@gmail.com","avatar":null},"body":"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\n\n\n! [main] Initial commit\n * [master] Initial commit\n  ! [origin/master] Initial commit\n---\n+*+ [main] Initial commit\n\nthe chunk of objects are on master and not main, and yet it shows\nnothing once checking out to master. \n\nthe git-clone operation is not consistent either. It's a disaster.\n\nOne would think that by now with the more developed work put on to git, it'd\nbe safe to assume the more sense there's on newer versions. But no. This\n is the opposite actually. \n\nNow. If by any chance the git-branch operation were to return:\n\n  main\n* master\n\nafter git-clone, then objects are indeed in place. That is. On master\n\nbut not if git-branch returns \n\n  main\n* master\n  origin/master\n\n\n\n-- \nThis login session: $13.99\n\n"},{"id":"477828","messageId":"ea3e1ea7-7f2e-4f15-b910-06c3cad54e24@app.fastmail.com","threadId":"59809","inReplyTo":"lxh4jpacuv5ivqp35w5vpbcjlw67r7ix3yog6cc3cu5ij7yqho@mrtr24xxdstx","subject":"Re: not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main","fromName":"Kristoffer Haugsbakk","fromEmail":"code@khaugsbakk.name","sentAt":"2023-05-31T10:08:31Z","receivedAt":"2023-05-31T10:08:56Z","isPatch":false,"sender":{"key":"code@khaugsbakk.name","avatar":"https://avatars.githubusercontent.com/u/2229597?v=4"},"body":"Hi\n\nOn Tue, May 30, 2023, at 20:14, Carlos wrote:\n> Running git 2.40.1 with HEAD -> master, origin/main, origin/HEAD,\n> origin/master, main with initial commit on main does not show all the\n> objects from master\n\nDoes this mean that `HEAD` and all of these other things point to the\nsame commit? Is this the output of `git log` with decorations?\n\nWhat are `main` and `master` meant to represent? One often doesn’t use\nboth of these names unless you have a legacy setup (originally `master`,\nthen moved to `main`).\n\nWhat can be confusing to me is that git(1) uses `master` as the default\nbranch name that you get after `git init`—this can be configured, but\n`master` is currently the default.[1] Meanwhile, GitHub uses `main` as\nthe default name. So what sometimes happens:\n\n1. Someone makes a local repository with `master` as the initial branch\n2. They make a repository on GitHub\n3. They click on “add a readme” or something\n4. Then GitHub creates a branch `main` with that readme addition on it\n5. They push their local changes and end up with two “default” branches:\n   `master` with their own changes, and `main` with the default readme\n\nMaybe both you (locally) and GitHub made commits named “Initial commit”?\n\n† 1: I’ve heard that the default might be `main` on Git For Windows, though?\n\n> ! [main] Initial commit\n>  * [master] Initial commit\n>   ! [origin/master] Initial commit\n> ---\n> +*+ [main] Initial commit\n>\n> the chunk of objects are on master and not main, and yet it shows\n> nothing once checking out to master.\n\nIt looks like both `master` and `main` point to the same commit.\n\nDo you have some command that you expected X output or behavior from,\nbut instead got Y output or behavior?\n\n> the git-clone operation is not consistent either. It's a disaster.\n\nWhat do you expect it to do and what actually happens?\n\nCheers\n\n-- \nKristoffer Haugsbakk\n"},{"id":"477829","messageId":"319cfa79-a508-127f-c201-9f50d5e6fe6a@iee.email","threadId":"59809","inReplyTo":"lxh4jpacuv5ivqp35w5vpbcjlw67r7ix3yog6cc3cu5ij7yqho@mrtr24xxdstx","subject":"Re: not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2023-05-31T10:57:56Z","receivedAt":"2023-05-31T10:58:03Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 30/05/2023 19:14, Carlos wrote:\n> 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\n> \n> \n> ! [main] Initial commit\n>  * [master] Initial commit\n>   ! [origin/master] Initial commit\n> ---\n> +*+ [main] Initial commit\n> \n\nthis is the output of `git show-branch` [1] which has its own special\ndisplay format. It's not often used these days.\n\nThe `!` are column markers, as is `*` for the current branch.\nYou have three branches listed\nThen you have the `---` divider\n\nFinally you has the single commit, showing which branches the commit is\n'on'.\n\nBe careful to discriminate between being 'on' a branch (at it's tip, by\nname); 'at' an oid (object id / hash); and `in` a branch (below its\ntip); etc.\n\n\n[1] https://git-scm.com/docs/git-show-branch\n\n> the chunk of objects are on master and not main, and yet it shows\n> nothing once checking out to master. \n> \n> the git-clone operation is not consistent either. It's a disaster.\n> \n> One would think that by now with the more developed work put on to git, it'd\n> be safe to assume the more sense there's on newer versions. But no. This\n>  is the opposite actually. \n> \n> Now. If by any chance the git-branch operation were to return:\n> \n>   main\n> * master\n> \n> after git-clone, then objects are indeed in place. That is. On master\n> \n> but not if git-branch returns \n> \n>   main\n> * master\n>   origin/master\n> \n> \n> \nPhilip\n"},{"id":"477831","messageId":"30385b42-0c6a-3588-2b13-0552c23727f2@iee.email","threadId":"59809","inReplyTo":"319cfa79-a508-127f-c201-9f50d5e6fe6a@iee.email","subject":"Re: not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2023-05-31T13:22:59Z","receivedAt":"2023-05-31T13:23:32Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 31/05/2023 11:57, Philip Oakley wrote:\n> On 30/05/2023 19:14, Carlos wrote:\n>> 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\n>>\n>>\n>> ! [main] Initial commit\n>>  * [master] Initial commit\n>>   ! [origin/master] Initial commit\n>> ---\n>> +*+ [main] Initial commit\n>>\n> \n> this is the output of `git show-branch` [1] which has its own special\n> display format. It's not often used these days.\n> \n> The `!` are column markers, as is `*` for the current branch.\n> You have three branches listed\n> Then you have the `---` divider\n> \n> Finally you has the single commit, showing which branches the commit is\n> 'on'.\n> \n> Be careful to discriminate between being 'on' a branch (at it's tip, by\n> name); 'at' an oid (object id / hash); and `in` a branch (below its\n> tip); etc.\n> \n> \n> [1] https://git-scm.com/docs/git-show-branch\n> \n>> the chunk of objects are on master and not main, and yet it shows\n>> nothing once checking out to master. \n>>\n>> the git-clone operation is not consistent either. It's a disaster.\n>>\n>> One would think that by now with the more developed work put on to git, it'd\n>> be safe to assume the more sense there's on newer versions. But no. This\n>>  is the opposite actually. \n>>\n>> Now. If by any chance the git-branch operation were to return:\n>>\n>>   main\n>> * master\n>>\n>> after git-clone, then objects are indeed in place. That is. On master\n>>\n>> but not if git-branch returns \n>>\n>>   main\n>> * master\n>>   origin/master\n>>\n\nYou may have accidentally created a local branch called `origin/master`\nwhich you are now confusing with the (unlisted) remote tracking branches.\n\nWhat does\n\n\tgit branch -ra\n\nproduce?\n\nIt will show the local branches first, and then your\n`remotes/repo/branches` list (probably colourised).\n\nThis should help confirm what you have.\n>>\n>>\n> Philip\nP.\n"},{"id":"477837","messageId":"a7xmox7j6katje62wx6hhclb7itfbhxnda44s4ve7g3cjyzm6j@2tosx6g6cpgv","threadId":"59809","inReplyTo":"30385b42-0c6a-3588-2b13-0552c23727f2@iee.email","subject":"Re: not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main","fromName":"Carlos","fromEmail":"kaploceh@gmail.com","sentAt":"2023-05-31T21:35:58Z","receivedAt":"2023-05-31T21:41:39Z","isPatch":false,"sender":{"key":"kaploceh@gmail.com","avatar":null},"body":"On Wed, May 31, 2023 at 02:22:59PM +0100, Philip Oakley wrote:\n> On 31/05/2023 11:57, Philip Oakley wrote:\n> > On 30/05/2023 19:14, Carlos wrote:\n> >> 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\n> >>\n> >>\n> >> ! [main] Initial commit\n> >>  * [master] Initial commit\n> >>   ! [origin/master] Initial commit\n> >> ---\n> >> +*+ [main] Initial commit\n> >>\n> > \n> > this is the output of `git show-branch` [1] which has its own special\n> > display format. It's not often used these days.\n> > \n> > The `!` are column markers, as is `*` for the current branch.\n> > You have three branches listed\n> > Then you have the `---` divider\n> > \n> > Finally you has the single commit, showing which branches the commit is\n> > 'on'.\n> > \n> > Be careful to discriminate between being 'on' a branch (at it's tip, by\n> > name); 'at' an oid (object id / hash); and `in` a branch (below its\n> > tip); etc.\n> > \n> > \n> > [1] https://git-scm.com/docs/git-show-branch\n> > \n> >> the chunk of objects are on master and not main, and yet it shows\n> >> nothing once checking out to master. \n> >>\n> >> the git-clone operation is not consistent either. It's a disaster.\n> >>\n> >> One would think that by now with the more developed work put on to git, it'd\n> >> be safe to assume the more sense there's on newer versions. But no. This\n> >>  is the opposite actually. \n> >>\n> >> Now. If by any chance the git-branch operation were to return:\n> >>\n> >>   main\n> >> * master\n> >>\n> >> after git-clone, then objects are indeed in place. That is. On master\n> >>\n> >> but not if git-branch returns \n> >>\n> >>   main\n> >> * master\n> >>   origin/master\n> >>\n> \n> You may have accidentally created a local branch called `origin/master`\n> which you are now confusing with the (unlisted) remote tracking branches.\n> \n\nif the remotes are in place, \n\n  main\n* master\n  origin/master\n  remotes/origin/HEAD -> origin/main\n  remotes/origin/main\n  remotes/origin/master\n\n\nwhat exactly is origin/master doing there? even by assuming I created it\n(which I didn't but let's say I did) then:\n\ngit checkout origin/master\n\nwarning: refname 'origin/master' is ambiguous.\nSwitched to branch 'origin/master'\n\nconfirms it that given the above, it follows that `git checkout\norigin/master` would fail to create and to be in quote  in 'detached\nHEAD' state. To look around, make experimental changes and commit them,\nand to discard any commits one makes in this state without impacting\nany branches by switching back to a branch` . blah blah blah\n\nas does the one without the origin/master , right? \n\nNow, if I were to do the same under the worktree (the tree holding the\ncontents correctly on both main and master, right?) with git branch -ra:\n\n\n  main\n* master\n  remotes/origin/HEAD -> origin/main\n  remotes/origin/main\n  remotes/origin/master\n\nwhich behaves accordingly\n\n* (HEAD detached at origin/master)\n  main\n  master\n  remotes/origin/HEAD -> origin/main\n  remotes/origin/main\n  remotes/origin/master\n\n\n> What does\n> \n> \tgit branch -ra\n> \n> produce?\n> \n> It will show the local branches first, and then your\n> `remotes/repo/branches` list (probably colourised).\n> \n> This should help confirm what you have.\n> >>\n> >>\n> > Philip\n> P.\n> \n\n-- \nModeling paged and segmented memories is tricky business.\n\t\t-- P. J. Denning\n\n"},{"id":"477840","messageId":"kewfqedoob2cptihhxoe6pp4jj63pw7qcldqvmb52cg7fbhzv5@xypplc3psbv5","threadId":"59809","inReplyTo":"a7xmox7j6katje62wx6hhclb7itfbhxnda44s4ve7g3cjyzm6j@2tosx6g6cpgv","subject":"Re: not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main","fromName":"Carlos","fromEmail":"kaploceh@gmail.com","sentAt":"2023-05-31T22:36:44Z","receivedAt":"2023-05-31T22:37:00Z","isPatch":false,"sender":{"key":"kaploceh@gmail.com","avatar":null},"body":"On Wed, May 31, 2023 at 05:35:58PM -0400, Carlos wrote:\n> On Wed, May 31, 2023 at 02:22:59PM +0100, Philip Oakley wrote:\n> > On 31/05/2023 11:57, Philip Oakley wrote:\n> > > On 30/05/2023 19:14, Carlos wrote:\n> > >> 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\n> > >>\n> > >>\n> > >> ! [main] Initial commit\n> > >>  * [master] Initial commit\n> > >>   ! [origin/master] Initial commit\n> > >> ---\n> > >> +*+ [main] Initial commit\n> > >>\n> > > \n> > > this is the output of `git show-branch` [1] which has its own special\n> > > display format. It's not often used these days.\n> > > \n> > > The `!` are column markers, as is `*` for the current branch.\n> > > You have three branches listed\n> > > Then you have the `---` divider\n> > > \n> > > Finally you has the single commit, showing which branches the commit is\n> > > 'on'.\n> > > \n> > > Be careful to discriminate between being 'on' a branch (at it's tip, by\n> > > name); 'at' an oid (object id / hash); and `in` a branch (below its\n> > > tip); etc.\n> > > \n> > > \n> > > [1] https://git-scm.com/docs/git-show-branch\n> > > \n> > >> the chunk of objects are on master and not main, and yet it shows\n> > >> nothing once checking out to master. \n> > >>\n> > >> the git-clone operation is not consistent either. It's a disaster.\n> > >>\n> > >> One would think that by now with the more developed work put on to git, it'd\n> > >> be safe to assume the more sense there's on newer versions. But no. This\n> > >>  is the opposite actually. \n> > >>\n> > >> Now. If by any chance the git-branch operation were to return:\n> > >>\n> > >>   main\n> > >> * master\n> > >>\n> > >> after git-clone, then objects are indeed in place. That is. On master\n> > >>\n> > >> but not if git-branch returns \n> > >>\n> > >>   main\n> > >> * master\n> > >>   origin/master\n> > >>\n> > \n> > You may have accidentally created a local branch called `origin/master`\n> > which you are now confusing with the (unlisted) remote tracking branches.\n> > \n> \n> if the remotes are in place, \n> \n>   main\n> * master\n>   origin/master\n>   remotes/origin/HEAD -> origin/main\n>   remotes/origin/main\n>   remotes/origin/master\n> \n> \n> what exactly is origin/master doing there? even by assuming I created it\n> (which I didn't but let's say I did) then:\n> \n> git checkout origin/master\n> \n> warning: refname 'origin/master' is ambiguous.\n> Switched to branch 'origin/master'\n> \n> confirms it that given the above, it follows that `git checkout\n> origin/master` would fail to create and to be in quote  in 'detached\n> HEAD' state. To look around, make experimental changes and commit them,\n> and to discard any commits one makes in this state without impacting\n> any branches by switching back to a branch` . blah blah blah\n> \n> as does the one without the origin/master , right? \n> \n\nFe de errata:\n\n*unlike the one without the origin/master, which *successfully* does,\nas shown below:\n\n> Now, if I were to do the same under the worktree (the tree holding the\n> contents correctly on both main and master, right?) with git branch -ra:\n> \n> \n>   main\n> * master\n>   remotes/origin/HEAD -> origin/main\n>   remotes/origin/main\n>   remotes/origin/master\n> \n> which behaves accordingly\n> \n> * (HEAD detached at origin/master)\n>   main\n>   master\n>   remotes/origin/HEAD -> origin/main\n>   remotes/origin/main\n>   remotes/origin/master\n> \n> \n> > What does\n> > \n> > \tgit branch -ra\n> > \n> > produce?\n> > \n> > It will show the local branches first, and then your\n> > `remotes/repo/branches` list (probably colourised).\n> > \n> > This should help confirm what you have.\n> > >>\n> > >>\n> > > Philip\n> > P.\n> > \n> \n> -- \n> Modeling paged and segmented memories is tricky business.\n> \t\t-- P. J. Denning\n> \n> \n\n-- \nPut no trust in cryptic comments.\n\n"}]}