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. > > I'm not worried about that now. These are two identical git-clone operations with different results in the end, from an end-user's perspective, that is. So in that sense, whether one is careful at being `on` the tip or `below` it doesn't matter really. Philip, let me take part of that back and say that it does matter but only theoretically speaking and assuming the curl operation behind while working with the remote behaved accordingly > > > > [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? main * master origin/master remotes/origin/HEAD -> origin/main remotes/origin/main remotes/origin/master whereas the one with what was to be expected is main * master remotes/origin/HEAD -> origin/main remotes/origin/main remotes/origin/master same git-clone operation for both with different results on the outset. The former barely holding up with contents from the main branch only. what's even funnier is that both git-checkout completions would return HEAD master origin/main main origin/HEAD origin/master as to be expected I guess And of course, origin/master is an illusion here which git presumably came up with > > 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. > -- The number of computer scientists in a room is inversely proportional to the number of bugs in their code.
