Re: Unexpected behavior with branch.*.{remote,pushremote,merge}
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