o2sh / onefetch

Command-line Git information tool

Home Page:https://onefetch.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Errs when invoked on partial clones

icp1994 opened this issue Β· comments

commented

Duplicates

  • I have searched the existing issues

Current behavior 😯

$ git clone --filter=blob:none https://github.com/sharkdp/fd
$ onefetch fd/
Error: sending on a closed channel

Expected behavior πŸ€”

I don't know if partial clones have some limitations which prevents onefetch from working so maybe erring is the expected behavior.

Steps to reproduce πŸ•Ή

No response

Additional context/Screenshots πŸ”¦

No response

Possible Solution πŸ’‘

No response

commented

Possible duplicate/related #978. Also, onefetch 2.18.0

Would you be willing to try out an earlier version? I'm curious if this was introduced in the recently released version.

commented

Works with v2.17.1

Thanks for checking!

The fact that it was introduced in v2.18, along with this error

Error: sending on a closed channel

Makes me think that this was introduced with our new file churn metric.

I'm thinking that maybe #1081 introduced this? πŸ€” Not implying that the changes in that PR should be undone -- I think they're good changes, including the changes that result in this error being raised πŸ™‚

.send errors were previously simply ignored by .send(foo).ok(), but now they're handled with .send(foo)?. I'm more used to concurrency in Go than Rust, so I'm a bit out of my depth here. But perhaps there can be an additional sender/receiver pair to send a stop signal, so that the sender knows that the receiver does not expect any more values? A bit less hack-y than ignoring errors on send attempts πŸ™‚ The receiver seems to be dropped before the sender finishes sending.

Again, from (hobby-level) Go experience, it looks a bit weird to me that the receiver is in the coroutine, and the sender is in the outer scope that calls the coroutine. I'm more used to it being the reverse. With the receiver in the outer scope, you should be able to be more confident that it won't be dropped (closed) before the sender stops sending.

commented

d5f8621 is the last "good" commit. With the next commit 1955153 I get:

$ onefetch /fd
Error: Could not find blob for similarity checking

Caused by:
    An object with id 0da0e9c3963daf5e99f99d2adbf825ce15090c58 could not be found

Same with fd1d5f0 and finally after the following commit 09c4dc9 it shows the current error.

Thanks for bisecting and finding the exact commits!

commented

Thanks! Tested locally, works as intended.