0

I'm facing weird (IMO) issues with my repo and start to question what I assumed. That is chaining of repos. Web search "git chaining repos" gave https://serverfault.com/questions/186161/possible-to-chain-git-repos where the answer "yes, of cause".

Now I just did git push origin HEAD:refs/remotes/origin/main in local (1st repo), in .git/config of 1st there is URL for origin (2nd repo).

In that 2nd repo in .git/config there is URL of 3rd repo as origin. But after push which outputted several objects in delta, I did not see those by git reflog on 2nd. Instead I saw in 2nd in refs/remotes/origin/main file hash of last commit pushed from 1st repo.

How do you think that happened? Maybe some internal `damage' to repo(s)? Other issues that lead me to investigate are in git fetch - "refuse", git pull "forced update, fetch updated current branch head". Local was 2 commits ahead of remote. TIA

git version 2.25.1

Added:

Yesterday repos seemed fine, I recall I first synced 1st and 2nd, then 2rd and 3nd, today I wanted to sync 1st and 2nd.

The only unusual thing I did I recall today after pull from 2nd to 1st there was a conflict, I did git reset FILE in 1st for file with that conflict and replaced (copied to repo folder) the file from backup outside of git.

Martian2020
  • 307
  • 3
  • 12

1 Answers1

0

git did what it was told to, push to origin HEAD:refs/remotes/origin/main, which is remote on remote.

When troubleshooting I noticed in .git/config entry for main was different, extra remotes. Apparently it set main to track main on remote's remote (further down the chain).

Also I recall I saw git-branch --set-upstream-to=main main produces effect of setting main branch to track origin's main and git-branch --set-upstream-to=origin/main main produce config change as described above. I was because I've made repo with git clone --mirror which sets refs translation in .git/config as fetch = +refs/*:refs/* whereas with regular clone: fetch = +refs/heads/*:refs/remotes/origin/*.

I think one needs to look attentively to output of the command to know the result.

To find out the cause of the issue included me running strace, seeing code only reads .git/config in user home, .git/config, .git/HEAD, .git/refs/heads/main and then realizing .git/config entry differs from entries for other repo (extra /remotes).

Martian2020
  • 307
  • 3
  • 12
  • `git-branch --set-upstream-to=main main`: this is valid but a *very bad idea*. It sets the upstream of `main` to be `main`. That's not a remote-tracking name, that's a local branch name. You can set the upstream of a branch `br2` to be local branch `br1` if you like; this means `git merge` and `git rebase` while on `br2` will use `br1` as the missing argument. It's not good with push and pull though since those are meant for transferring commits to/from *another repository* and in this case, the "other Git" is *your own* repository, so there's never anything to transfer. – torek Dec 11 '22 at 08:28
  • 1
    There are a few special purpose uses for `git push . br1:br2` or `git fetch . br2:br1`, if you want to attempt fast-forwarding one local branch name via another local branch name. But that's not what you want here. (Note that in this case, the "URL" of `.` refers to the current directory => use the local Git repository as if it were a second Git repository). – torek Dec 11 '22 at 08:28
  • @torek, thanks for trying to help. I now guess all issues are from some perculiar set of refs and config file of the repo. I'm trying to reperform with simple repos from init/clone and cannot arrive at my issues (yet). – Martian2020 Dec 12 '22 at 12:35