upload-pack not our ref

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux