git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Unexpected behavior with branch.*.{remote,pushremote,merge}

From
BDBen Denhartog <ben@sudoforge.com>
Date
Oct 10, 2020, 18:27 UTC
Message-ID
<dab3f28e-1a4b-4756-9a50-a5804b438804@www.fastmail.com>
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@sudoforge.com
Next: Ben Denhartog
Message 1 of 2 in “Unexpected behavior with branch.*.{remote,pushremote,merge}”
  1. Ben DenhartogOct 10, 2020
  2. Ben DenhartogOct 10, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.