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

["Ben Denhartog" <ben@sudoforge.com>]

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@sudoforge.com

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@sudoforge.com