There's a small typo that I didn't catch here -- `branch.main.merge` should be `refs/heads/main` in this example. Rest assured this is not the source of my issue (the actual repository I used for this still uses `master` as `HEAD`) -- Ben Denhartog ben@xxxxxxxxxxxxx On Sat, Oct 10, 2020, at 12:27, Ben Denhartog wrote: > I have a few repositories on my system that exist primarily as local > copies of remote repositories, in that I normally just want to track > and follow the upstream project (however, I periodically contribute > back upstream so they are technically forks -- origin is my remote, > upstream is theirs). > > In these repositories, I set the following configuration: > > ``` > [remote "origin"] > url = https://git.foo.com/me/bar.git > fetch = +refs/heads/*:refs/remotes/origin/* > [remote "upstream"] > url = https://git.foo.com/them/bar.git > fetch = +refs/heads/main:refs/remotes/upstream/main > tagopt = --no-tags > [branch "main"] > remote = upstream > pushRemote = origin > merge = refs/heads/master > rebase = true > ``` > > Based on my understanding, this should effectively force my local > `main` branch to track against `upstream/main`, but push to > `origin/main`. I notice some odd behavior when fetching, primarily that > FETCH_HEAD doesn't resolve to `upstream/main` as I would expect: > > ``` > ➜ git fetch --all > Fetching origin > Fetching upstream > remote: Enumerating objects: 23, done. > remote: Counting objects: 100% (23/23), done. > remote: Total 32 (delta 23), reused 23 (delta 23), pack-reused 9 > Unpacking objects: 100% (32/32), 12.97 KiB | 949.00 KiB/s, done. > From https://git.foo.com/them/bar > 63f7159..e65b80e main -> upstream/main > > > ➜ git status -sbu > ## main...upstream/main [behind 9] > > > ➜ git rev-parse HEAD upstream/main origin/main FETCH_HEAD > 63f71597979edb16cb9f80d0431115e22dcb716d > e65b80edd2a2162f67120a98e84bb489f15fcf97 > 23e6881719f661c37336d9fcf7a9005a7dfce0cf > 23e6881719f661c37336d9fcf7a9005a7dfce0cf > ``` > > As we see from the output, `FETCH_HEAD` is resolving to the same commit > as `origin/main`, when I would instead expect it to resolve to the same > commit as `upstream/main`. Here are the contents of `.git/FETCH_HEAD` > in its entirety: > > ``` > ➜ cat .git/FETCH_HEAD > 23e6881719f661c37336d9fcf7a9005a7dfce0cf not-for-merge branch > 'main' of https://git.foo.com/me/foo > e65b80edd2a2162f67120a98e84bb489f15fcf97 branch 'main' > of https://git.foo.com/them/foo > ``` > > Curiously, `git rebase FETCH_HEAD` seems to think the local branch is > up to date (erroneously), however `git-pull --rebase=true` and > `git-merge FETCH_HEAD` both work as expected and merge/rebase with > `upstream/main`. > > Am I going about this incorrectly? The main purpose behind configuring > my "mostly just a fork" repository is that it simplifies tracking > against an upstream remote for projects which I do not work on > actively. Of course, you might argue that I don't need to keep my > remote around for this purpose and can just use a straightforward > `git-clone` here -- but I'd rather not, and would prefer responses > addressing the perceived bug rather than suggesting this particular > alternative workflow. > > -- > Ben Denhartog > ben@xxxxxxxxxxxxx
