Somehow I have managed to intertwine two branches in my local repository. They are ‘assert’ and ‘lists’. Here is what I see:
Switched to branch ‘assert’
c:\llvm\llvm-project> git log2
14580ce2fdd1 (HEAD → assert, origin/main, origin/HEAD, main, lists) [TableGen] Make behavior of list slice suffix consistent across all values
3b9a15d910a8 [TableGen] Add support for the ‘assert’ statement in multiclasses
Since you’ve already pushed, upstream should be considered source of truth. If I were you, I would start a new branch, pull fresh from upstream and then git cherrypick commits you want to keep from your local branches into the new branch. The git reflog is your friend on this, especially if you start resetting, etc.
Since I see you are on Windows, I recall some of these things to be fairly easy with the Forks git gui.
There are probably better ways to repair, but for me, when I mess it all up, I find it easier to low tech reconstruct what I want vs advanced solutions.
When I check out the main branch, do a pull --rebase, and ask for a log, I see the following. That line with ‘(lists, assert)’ seems funky.
c:\llvm\llvm-project> git log --oneline -30 2690d4d45a63 (HEAD -> main, origin/main, origin/HEAD) [MLIR] Support symbols in emptiness checks for FlatAffineConstraints e10493eb5012 [DebugInfo] Correctly track SDNode dependencies for list debug values e184eeaa3ba1 [AMDGPU] Add some implicit uses to tests. NFC. a1a372dfb526 [AMDGPU] SIFoldOperands: remove an unneeded isReg check. NFC. 2cb8c10342ee Revert "Reduce the number of attributes attached to each function" 466fab5c9410 [lsan] Mark 2 new lsan tests unsupported on arm-linux 2ecf928153fc [lldb/DWARF] Fix a crash parsing invalid dwarf (pr49678) 1e511bb1be71 [lldb] Re-skip TestVSCode_launch 9229465bad85 [NFC] Fix warning introduced in 20105b6b4874a85813f7a4a3d8ad2a0f023dda14 a250e91d1034 [AMDGPU] SIFoldOperands: make use of emplace_back. NFC. 2724b57ecdbb [AMDGPU] SIFoldOperands: remove an unneeded make_early_inc_range. NFC. c28f79a0e335 [AMDGPU] SIFoldOperands: try harder to fold cndmask instructions e4de3cdf3d66 [LV] Pass VPWidenPHIRecipe to widenPHIInstruction (NFC). 9f0d8bac144c [analyzer] Fix dead store checker false positive b785e03612d7 Support: mapped_file_region: Pass MAP_NORESERVE to mmap 3344cd3a1477 [AMDGPU] SIFoldOperands: make tryFoldCndMask a member function. NFC. c10cc4ea2729 [AMDGPU] Fix computing live registers in prolog 6fccfd7cbdca [InstCombine] add icmp with no-wrap add tests; NFC 14580ce2fdd1 (lists, assert) [TableGen] Make behavior of list slice suffix consistent across all values 3b9a15d910a8 [TableGen] Add support for the 'assert' statement in multiclasses 1206313f82f8 [CodeGen][AArch64] Fix isel crash for truncating FP stores 5299843c3146 [mlir][spirv] Add control for non-32-bit scalar type emulation 004f29c0bb3c [mlir][spirv] Timely fail type conversion
Branches are just a pointer to a commit ID. This just means that your local main, lists, and assert branches all point to the same commit ID, which is OK. Pushing one does not push the others. When you push a branch e.g. lists via git push origin lists, what you are doing is telling the remote server “create or change the branch (pointer) on your end called lists to refer to the same commit ID as my local branch lists”. It also pushes the commits to the server (but this is strictly additive - nothing is lost by this action). No other remote branches would be affected by this action.
It’s also possible to push a local branch to a remote branch with a different name; e.g. git push origin foo:bar makes a branch called bar on the remote side with the same commit ID as the branch called foo on the local side.
Overall I don’t think you’ve broken anything, it’s just that the log output is not completely intuitive. It’s just listing all the branch names that it knows of which happen to point to the corresponding commit ID in the log.
But two things are confusing. I only pushed the ‘lists’ branch, not the ‘assert’ branch, yet both revisions are up on GitHub. I suppose I should be careful and say that if I pushed ‘assert’, I don’t know how I did it.
Also, if you check the dates on the changed lines in the various files, they are dated April 5 for ‘lists’ and April 1 for ‘assert’. But I amended the commit on the ‘lists’ branch today and then pushed it.
According to that log, neither lists nor assert appear on your GitHub instance with those commit IDs (if you had successfully pushed lists, you should expect lists to have the same commit ID as origin/lists, which does not appear in your log at all).
And it’s worth noting that amending a commit does not change the commit date, unless you explicitly tell it to do so. You can see the separate authorship and commit dates using git log --pretty=fuller. But what you see in annotations is probably the authorship date.
I'm sorry, I don't understand your first paragraph. When I ask for a list of commits at GitHub, I see what I've included below. I'm also confused by 'origin/lists'. Why would there be a 'lists' branch on origin?
When working with GitHub, it is common to use the origin remote to correspond to your fork of the project. It’s idiomatic to use upstream to refer to the upstream project. So when you said you pushed up “both revisions” I assume you meant that you pushed one or both branches to your fork, via origin. If your origin points to the upstream repository, I would expect a “push” to fail unless you have the appropriate permissions to create a new branch on the upstream repository. Since I don’t see a lists or assert branch on the upstream LLVM repository, I would conclude that this must be the case.
To answer your question: Git keeps a copy of the branch pointers for every remote that you fetch from or push to (in Git, a “pull” is a “fetch” followed by a “merge”). So when you see origin/xxx in your log, that refers to the commit that branch xxx on origin was pointing to when you last fetched from or pushed to it. If you had pushed anything anywhere, I would expect there to be a branch name in the commit log corresponding to the remote branch (origin/xxx) as well as the local one (xxx).
Somehow I have managed to intertwine two branches in my local repository. They are 'assert' and 'lists'. Here is what I see:
Switched to branch 'assert'
c:\llvm\llvm-project> git log2
14580ce2fdd1 (HEAD -> assert, origin/main, origin/HEAD, main, lists) [TableGen] Make behavior of list slice suffix consistent across all values
3b9a15d910a8 [TableGen] Add support for the 'assert' statement in multiclasses
Switched to branch 'lists'
c:\llvm\llvm-project> git log2
14580ce2fdd1 (HEAD -> lists, origin/main, origin/HEAD, main, assert) [TableGen] Make behavior of list slice suffix consistent across all values
3b9a15d910a8 [TableGen] Add support for the 'assert' statement in multiclasses
from commit SHA they look same branch to me. what cmds did you use to
switch from assert to lists branch ? you can use git reflog to
inspect your tree and see where things changed