Feature request: a verbose mode that also shows why repos aren't available for updates
siebenmann opened this issue · 8 comments
I'll start with my motivating story. One day, I somehow wound up with $GIT_WORK_TREE accidentally set in my shell environment when I ran Go-Package-Store. In this state, G-P-S reported that no packages had updates, although a gostatus all in another window showed that they did. Diagnosing this wound up being fiendishly difficult, and eventually I discovered that G-P-S was silently rejecting repos because it thought there were uncommitted changes in every (Git) repo it was checking.
So: What I'd like to see as a feature for Go-Package-Store is a verbose mode where G-P-S reports in some way on repos that it isn't willing to update and why, at least for things like 'uncommitted local changes' or 'can't find the upstream'. I'd be happy with a report that was just printed to standard out, although I think it'd be great if it could be shown in the browser instead (although that's probably more work). If this is too much work, I think it might be good to just add a little postscript to the web page saying something like 'this report excludes repositories with local changes' or the like, because until I went digging into the G-P-S source I actually had no idea that it did this.
(Hopefully what I accidentally did with $GIT_WORK_TREE is rare enough that there's no point in checking for this and similar environment variable mistakes.)
Hi, thanks for reporting this.
This is a very valid request, and I'll think about resolving this.
I've known about this for some time, and I agree the current situation of GPS silently ignoring repos with unclean status (without notifying the user in any way) is not optimal.
gostatus all is a great tool to diagnose and resolve issues, but GPS could at least display packages that have updates but it can't update (because, for example, a non-default branch is checked out, or there are uncommitted changes in working directory, etc.).
G-P-S was silently rejecting repos because it thought there were uncommitted changes in every (Git) repo it was checking.
To clarify, did it think there uncommitted changes because there were actually uncommitted changes, or was it falsely detecting that, and it wasn't the case?
Based on git status --porcelain output, Go-Package-Store correctly thought that everything had uncommitted changes because that's what got reported to it. This was ultimately because I had $GIT_WORK_TREE set, so git status was comparing each repo against a completely unrelated work tree and of course basically reporting 'tons of stuff is gone, tons of stuff is new, and oh there's some overlap but it's almost all got changes'. I can't exactly blame either G-P-S or git status for this, and the problem went away when I worked out that I had somehow got $GIT_WORK_TREE set in my environment and removed it.
I see, thanks for the heads up. I'll think if there's any way to prevent such false-positives in the future. But ultimately, GPS relies the git command in the environment, so it will be susceptible to misconfiguration like that (and git has so many flags and env vars...).
An update here. As of c74ea9f, GPS prints a little more to stderr when some repositories are skipped. It doesn't resolve this issue completely, but it helps.
@mvdan also ran into this #64.
I just realized that the stderr skip messages are only printed for remote errors. But nothing gets printed for repositories that are skipped for non-error reasons:
Go-Package-Store/workspace/workspace.go
Lines 532 to 534 in 093c972
I'll work on resolving that.
Confirming this fixes it, found another repo in the same state as the one I mentioned:
skipping "github.com/xanzy/go-gitlab" because:
working tree is dirty:
M projects.go