All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ben Denhartog" <ben@sudoforge.com>
To: git@vger.kernel.org
Subject: Unexpected behavior with branch.*.{remote,pushremote,merge}
Date: Sat, 10 Oct 2020 12:27:32 -0600	[thread overview]
Message-ID: <dab3f28e-1a4b-4756-9a50-a5804b438804@www.fastmail.com> (raw)

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

             reply	other threads:[~2020-10-10 22:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-10 18:27 Ben Denhartog [this message]
2020-10-10 18:38 ` Unexpected behavior with branch.*.{remote,pushremote,merge} Ben Denhartog
2020-12-04  1:26 Ben Denhartog
2020-12-04  2:31 ` Felipe Contreras
2020-12-04 16:44   ` Ben Denhartog
2020-12-04 21:29     ` Felipe Contreras
2020-12-04 10:13 ` Jeff King
2020-12-04 16:45   ` Ben Denhartog
2020-12-04 19:57     ` Junio C Hamano
2020-12-04 21:00       ` Jeff King
2020-12-04 22:20         ` Ben Denhartog

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dab3f28e-1a4b-4756-9a50-a5804b438804@www.fastmail.com \
    --to=ben@sudoforge.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.