# upload-pack not our ref

1 messages from 2023-04-12 to 2023-04-12. Participants: Sam Darwin.
Thread: https://gitlist.dev/t/59585

## Sam Darwin, 2023-04-12 13:58

Subject: upload-pack not our ref
Message-ID: <CANEqPjHpaYvBWUy-pMi6ikhE6BeVooEBPK+O=cRzafD7o0UwaA@mail.gmail.com>
URL: https://gitlist.dev/e/CANEqPjHpaYvBWUy-pMi6ikhE6BeVooEBPK%2BO%3DcRzafD7o0UwaA%40mail.gmail.com

```
Hi,

I've just run into something which really looks like a bug in git.
But I expect you will explain the reasoning that it's not a bug.  Let's see.
There is a superproject with submodules. Check it out locally. Update
a few of the submodules: "git submodule update"
Then, wait a few weeks.
Upstream, commits change on both the superproject and submodules.
Refresh the local copy:
git pull
It gives an error about one of the submodules:
fatal: remote error: upload-pack: not our ref
19127b75621f423b572281f27b92ce4c7e50f1b5
The submodule that triggers the error already happens to be
up-to-date, so it won't actually be updated or changed during "git
pull".
Nothing changed on that submodule, and it hadn't been force-pushed, as
far as I can tell.  No commits were made in the intervening time
period on that specific submodule.  (maybe tags were
changed/updated...)
On the superproject and some other modules, yes there were modifications.
"19127b75621f423b572281f27b92ce4c7e50f1b5" is a mystery, and isn't the
main commit sha (either before or after).
Changing the command from "git pull" to "git pull
--no-recurse-submodules ;  git submodule update" fixes things.
So, switching to a two-step process somehow avoids the error.
What is the difference between  "git pull" and the combination of "git
pull --no-recurse-submodules ;  git submodule update" ?  ( that seems
like the crux of the matter ).
The error appears with git versions 2.36 and 2.40.  Not git version
2.17.1.  ( also interesting.. )

Thanks,
Sam

```