From: Carlos <kaploceh@gmail.com>
To: git@vger.kernel.org
Subject: Re: not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main
Date: Wed, 31 May 2023 17:35:58 -0400 [thread overview]
Message-ID: <a7xmox7j6katje62wx6hhclb7itfbhxnda44s4ve7g3cjyzm6j@2tosx6g6cpgv> (raw)
In-Reply-To: <30385b42-0c6a-3588-2b13-0552c23727f2@iee.email>
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
next prev parent reply other threads:[~2023-05-31 21:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-30 18:14 not robust inconsistent git 2.40.1 with HEAD -> master, origin/main, origin/HEAD, origin/master, main 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 [this message]
2023-05-31 22:36 ` Carlos
-- strict thread matches above, loose matches on Subject: below --
2023-05-30 17:58 Carlos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a7xmox7j6katje62wx6hhclb7itfbhxnda44s4ve7g3cjyzm6j@2tosx6g6cpgv \
--to=kaploceh@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).