Bad output on 'git bug pull' #867

Activity

1. MichaelMure commented on Sep 14, 2022

   

   MichaelMure

   on Sep 14, 2022

   Contributor

   More actions

   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.
2. smoyer64 commented on Oct 1, 2022

   

   smoyer64

   on Oct 1, 2022

   Collaborator

   More actions

   This looks like a good argument for passing stderr into the repository package as discussed in #891 (comment). 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).
3. MichaelMure commented on Oct 24, 2022

   

   MichaelMure

   on Oct 24, 2022

   Contributor

   More actions

   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.
4. smoyer64 commented on Oct 24, 2022

   

   smoyer64

   on Oct 24, 2022

   Last edited by smoyer64

   Collaborator

   More actions

   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:

   https://github.com/MichaelMure/git-bug/blob/55a2e8e4485fe63fbda759540958c7190dfeb85c/cache/repo_cache_common.go#L76-L88

   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.
5. MichaelMure commented on Oct 24, 2022

   

   MichaelMure

   on Oct 24, 2022

   Contributor

   More actions

   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.
6. MichaelMure

   closed this as completedin #938on Dec 23, 2022