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.
