When running git bug pull on a repository that is already up-to-date, the already up-to-date message is displayed twice:
$ git bug pull
Fetching remote ...
already up-to-datealready up-to-date
Merging data ...
git-bug version: 0.7.1-dev-d0db3b121b
Unfortunately, this is going to be a bit tricky to fix properly as the way to bubble up those messages from deeper layer of git-bug need to be reworked a bit.
This looks like a good argument for passing stderr into the repository package as discussed in https://github.com/MichaelMure/git-bug/pull/891#issuecomment-1264424060. I would argue that the above message isn't actually incorrect as the first copy of the repeated string is fetching refs for identities and the second is fetching refs for entities (in this case bugs).
The thing I've been thinking about is something like this:
type BuildEvent struct {
Error error
EntityName string
Done bool
// Progress float32 // later, maybe?
}
func (c *RepoCache) buildCache() chan BuildEvent{
...
Then each UI can format that however make sense.
That's eerily similar to what I was typing in a new issue (presuming this one is closed with the "quick" fix). For reference, this behavior also needs to be passed through the caching layer at:
I'd suggest that we also pass the entity "type" with each BuildEvent and define this type at the core (maybe as RemoteEvent instead?). RepoCache.Fetch can loop through Identities, Bugs, PRs, Boards and the events can simply be merged into the output of func (c *RepoCache) Fetch(remote string) chan BuildEvent.
With a little care, we can use the Scatter-Gather pattern to execute the remote fetches in parallel too but the UIs would need to know that there's no guarantee on the ordering. Of course, if executed sequentially, the UIs still need to know the type of an entity to present something meaningful to the user.
I'd suggest that we also pass the entity "type" with each
BuildEvent
I was thinking about the Typename that you can find in the entity definition.
RepoCache.Fetch is another good candidate for that kind of event, but let's have a different event type. That way we have a clean and obvious cache.BuildEvent and cache.FetchEvent, with their own things.