{"thread":{"id":"54383","subject":"Unexpected behavior with branch.*.{remote,pushremote,merge}","startedAt":"2020-10-10T22:51:44Z","lastAt":"2020-10-10T22:56:06Z","messageCount":2,"participants":["Ben Denhartog"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"407262","messageId":"dab3f28e-1a4b-4756-9a50-a5804b438804@www.fastmail.com","threadId":"54383","inReplyTo":null,"subject":"Unexpected behavior with branch.*.{remote,pushremote,merge}","fromName":"Ben Denhartog","fromEmail":"ben@sudoforge.com","sentAt":"2020-10-10T18:27:32Z","receivedAt":"2020-10-10T22:51:44Z","isPatch":false,"sender":{"key":"ben@sudoforge.com","avatar":null},"body":"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).\n\nIn these repositories, I set the following configuration:\n\n```\n[remote \"origin\"]\n  url = https://git.foo.com/me/bar.git\n  fetch = +refs/heads/*:refs/remotes/origin/*\n[remote \"upstream\"]\n  url = https://git.foo.com/them/bar.git\n  fetch = +refs/heads/main:refs/remotes/upstream/main\n  tagopt = --no-tags\n[branch \"main\"]\n  remote = upstream\n  pushRemote = origin\n  merge = refs/heads/master\n  rebase = true\n```\n\nBased 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:\n\n```\n➜ git fetch --all\nFetching origin\nFetching upstream\nremote: Enumerating objects: 23, done.\nremote: Counting objects: 100% (23/23), done.\nremote: Total 32 (delta 23), reused 23 (delta 23), pack-reused 9\nUnpacking objects: 100% (32/32), 12.97 KiB | 949.00 KiB/s, done.\nFrom https://git.foo.com/them/bar\n   63f7159..e65b80e  main     -> upstream/main\n\n\n➜ git status -sbu\n## main...upstream/main [behind 9]\n\n\n➜ git rev-parse HEAD upstream/main origin/main FETCH_HEAD\n63f71597979edb16cb9f80d0431115e22dcb716d\ne65b80edd2a2162f67120a98e84bb489f15fcf97\n23e6881719f661c37336d9fcf7a9005a7dfce0cf\n23e6881719f661c37336d9fcf7a9005a7dfce0cf\n```\n\nAs 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:\n\n```\n➜ cat .git/FETCH_HEAD\n23e6881719f661c37336d9fcf7a9005a7dfce0cf        not-for-merge   branch 'main' of https://git.foo.com/me/foo\ne65b80edd2a2162f67120a98e84bb489f15fcf97                branch 'main' of https://git.foo.com/them/foo\n```\n\nCuriously, `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`.\n\nAm 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.\n\n-- \n  Ben Denhartog\n  ben@sudoforge.com\n"},{"id":"407263","messageId":"77a13a76-89b2-4fd7-91d8-1b9e47a5bc37@www.fastmail.com","threadId":"54383","inReplyTo":"dab3f28e-1a4b-4756-9a50-a5804b438804@www.fastmail.com","subject":"Re: Unexpected behavior with branch.*.{remote,pushremote,merge}","fromName":"Ben Denhartog","fromEmail":"ben@sudoforge.com","sentAt":"2020-10-10T18:38:25Z","receivedAt":"2020-10-10T22:56:06Z","isPatch":false,"sender":{"key":"ben@sudoforge.com","avatar":null},"body":"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`)\n\n-- \n  Ben Denhartog\n  ben@sudoforge.com\n\nOn Sat, Oct 10, 2020, at 12:27, Ben Denhartog wrote:\n> I have a few repositories on my system that exist primarily as local \n> copies of remote repositories, in that I normally just want to track \n> and follow the upstream project (however, I periodically contribute \n> back upstream so they are technically forks -- origin is my remote, \n> upstream is theirs).\n> \n> In these repositories, I set the following configuration:\n> \n> ```\n> [remote \"origin\"]\n>   url = https://git.foo.com/me/bar.git\n>   fetch = +refs/heads/*:refs/remotes/origin/*\n> [remote \"upstream\"]\n>   url = https://git.foo.com/them/bar.git\n>   fetch = +refs/heads/main:refs/remotes/upstream/main\n>   tagopt = --no-tags\n> [branch \"main\"]\n>   remote = upstream\n>   pushRemote = origin\n>   merge = refs/heads/master\n>   rebase = true\n> ```\n> \n> Based on my understanding, this should effectively force my local \n> `main` branch to track against `upstream/main`, but push to \n> `origin/main`. I notice some odd behavior when fetching, primarily that \n> FETCH_HEAD doesn't resolve to `upstream/main` as I would expect:\n> \n> ```\n> ➜ git fetch --all\n> Fetching origin\n> Fetching upstream\n> remote: Enumerating objects: 23, done.\n> remote: Counting objects: 100% (23/23), done.\n> remote: Total 32 (delta 23), reused 23 (delta 23), pack-reused 9\n> Unpacking objects: 100% (32/32), 12.97 KiB | 949.00 KiB/s, done.\n> From https://git.foo.com/them/bar\n>    63f7159..e65b80e  main     -> upstream/main\n> \n> \n> ➜ git status -sbu\n> ## main...upstream/main [behind 9]\n> \n> \n> ➜ git rev-parse HEAD upstream/main origin/main FETCH_HEAD\n> 63f71597979edb16cb9f80d0431115e22dcb716d\n> e65b80edd2a2162f67120a98e84bb489f15fcf97\n> 23e6881719f661c37336d9fcf7a9005a7dfce0cf\n> 23e6881719f661c37336d9fcf7a9005a7dfce0cf\n> ```\n> \n> As we see from the output, `FETCH_HEAD` is resolving to the same commit \n> as `origin/main`, when I would instead expect it to resolve to the same \n> commit as `upstream/main`. Here are the contents of `.git/FETCH_HEAD` \n> in its entirety:\n> \n> ```\n> ➜ cat .git/FETCH_HEAD\n> 23e6881719f661c37336d9fcf7a9005a7dfce0cf        not-for-merge   branch \n> 'main' of https://git.foo.com/me/foo\n> e65b80edd2a2162f67120a98e84bb489f15fcf97                branch 'main' \n> of https://git.foo.com/them/foo\n> ```\n> \n> Curiously, `git rebase FETCH_HEAD` seems to think the local branch is \n> up to date (erroneously), however `git-pull --rebase=true` and \n> `git-merge FETCH_HEAD` both work as expected and merge/rebase with \n> `upstream/main`.\n> \n> Am I going about this incorrectly? The main purpose behind configuring \n> my \"mostly just a fork\" repository is that it simplifies tracking \n> against an upstream remote for projects which I do not work on \n> actively. Of course, you might argue that I don't need to keep my \n> remote around for this purpose and can just use a straightforward \n> `git-clone` here -- but I'd rather not, and would prefer responses \n> addressing the perceived bug rather than suggesting this particular \n> alternative workflow.\n> \n> -- \n>   Ben Denhartog\n>   ben@sudoforge.com\n"}]}