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
Dec 4, 2020, 01:26 UTC
Message-ID
<a4ae4e1a-b457-4b35-878c-2714ebfc415f@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 of the branch configuration options, this should effectively force my local `main` branch to track against `upstream/main`, but push to `origin/main`. I notice what I believe to be odd behavior when fetching: 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: Felipe Contreras
Message 1 of 9 in “Unexpected behavior with branch.*.{remote,pushremote,merge}”
  1. Ben DenhartogDec 4, 2020
  2. Felipe ContrerasDec 4, 2020
  3. Ben DenhartogDec 4, 2020
  4. Felipe ContrerasDec 4, 2020
  5. Jeff KingDec 4, 2020
  6. Ben DenhartogDec 4, 2020
  7. Junio C HamanoDec 4, 2020
  8. Jeff KingDec 4, 2020
  9. Ben DenhartogDec 4, 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.