Check stderr for output, that's where git fetch writes to by default#603
Conversation
| return len(outBuf.Bytes()) != 0 | ||
| return len(errBuf.Bytes()) != 0 | ||
| } | ||
| return false |
There was a problem hiding this comment.
The code (not your fix) is a bit janky. Would you mind cleaning it up a bit while you are at it? EG we could remove the else block and return early if cmd.Run() returns with an error.
There was a problem hiding this comment.
Don't mind at all! I'll give it a shot later today.
There was a problem hiding this comment.
Alright, went a little further than just changing the else block, let me know what you think.
Here's a screenshot from some print debugs to make sure it works as expected.
One thing to note for the future, as far as I can tell fetch prints actual errors to stderr as well sometimes, if we really want to be fancy we can probably switch to the --porcelain (introduced here) mode to ensure that what's printed is actually an update...
There was a problem hiding this comment.
One thing to note for the future, as far as I can tell fetch prints actual errors to stderr as well sometimes, if we really want to be fancy we can probably switch to the --porcelain (introduced here) mode to ensure that what's printed is actually an update...
That looks nice indeed!
Thanks for taking a look! |
This is another little bugfix I've used for a while and forgot to commit up -
I added some logic in the
periodicFetchfunction so that repos were only re-indexed if they had a fetch update, or it'd beennhours since a brute-reindex. Then I started noticing that repos that definitely had an update weren't getting re-indexed, traced the problem down and found this.It's not a particularly elegant solution, I'm happy to modify it to be nicer. I kept
outBufaround in case git ever decides to print to it & the cmd errors, in that case it'd probably be useful for debugging.