On Fri, Jun 2, 2023 at 1:26 PM <rsbecker@xxxxxxxxxxxxx> wrote: > > On Friday, June 2, 2023 3:53 PM, Paul Smith wrote: > >On Fri, 2023-06-02 at 15:34 -0400, rsbecker@xxxxxxxxxxxxx wrote: > >> On Friday, June 2, 2023 3:13 PM, Paul Smith wrote: > >> > On Fri, 2023-06-02 at 14:59 -0400, Paul Smith wrote: > >> > > Also a bunch of the heads are missing. It's pretty clear that > >> > > right in the middle of printing one of the SHAs we suddenly lost a > >> > > bunch of output, and started printing stuff from later (in the > >> > > last instance 66 out of 131 heads were missing). > >> > > >> > I forgot to mention: git ls-remote does not exit with an error code. > >> > The exit code is 0 (success). > >> > > >> > The reason I get this failure is that as I parse the output I notice > >> > that the SHA is invalid (contains a non-hex character "i") and it > >> > throws this error. > >> > >> Does your CI/CD system use sparse checkout or depth=1 or some other > >> partial clone? > > > >Yes, the local copy of the repo is a sparse checkout. > > > >I'm surprised that matters to ls-remote... I would have expected that the "sparseness" > >of the local repo is irrelevant when listing the state of the remote's heads? Is that > >the reason for the issue I'm seeing? > > I'm just wondering whether this might be an impact somehow and adding info to help the team diagnose. I have seen other commands have some issues in the past with --depth=n > --Randall I think if shallowness or sparseness affected ls-remote output in any way whatsoever, that would itself be a bug. Granted, I don't know much about the protocol side of things, but I'd be very surprised if either of these conditions mattered.
