benthayer / git-gud

Wanna git gud? Then get git-gud, and git gud at git!
MIT License
401 stars 42 forks source link

Implement logging and Git Gud Error #308

Closed sahansk2 closed 3 years ago

sahansk2 commented 3 years ago

Fixes #279

sahansk2 commented 3 years ago

This is very much not ready for review. I will undraft this PR when it is.

benthayer commented 3 years ago

@sahansk2 Does this actually solve #279? There are two specific things we wanted to log, can you add them? This is simple enough to get us started and hopefully to get into the habit of logging errors using the logger.

On another note, do you think we should convert all print statements to use the logger?

benthayer commented 3 years ago

Also, can you merge master so you can get the GitHub Actions

sahansk2 commented 3 years ago

This will solve #279, but it doesn't right now. I wanted to make a draft PR ahead of time so that we could double check on progress as it's developed.

The biggest issues that I have right now are basically:

We shouldn't convert everything to logging (see here), but we could definitely convert some print messages to logging (e.g. Current level doesn't exist.)

benthayer commented 3 years ago

@sahansk2 Does this help? https://stackoverflow.com/questions/11232230/logging-to-two-files-with-different-settings

benthayer commented 3 years ago

I think for logging, we can take a simple first approach of simply logging things whenever we think it's necessary, so if there's an exception, include a line with logger.info(information)

sahansk2 commented 3 years ago

@sahansk2 Does this help? https://stackoverflow.com/questions/11232230/logging-to-two-files-with-different-settings

Unfortunately, not really. It would be a bit of a hassle on our end to always output to two loggers, one error.txt and one YYYY-MM-DD-HH-mm.txt.

I just thought of this, though: what do you think about having a wrapper function, gitgud_logger(*args, **kwargs) that sends args and kwargs to two logger objects simultaneously? That would make logging much easier for us, and we can also use the two-file approach with error.txt and the time-specific file.

benthayer commented 3 years ago

I see what you mean. What if when users had errors, we just logged it all to one file and had them send that file to us?

I think that could be good for a first iteration. Right now, we're not even sure how errors will be coming up

sahansk2 commented 3 years ago

I see what you mean. What if when users had errors, we just logged it all to one file and had them send that file to us?

That could work, but it might be difficult from a development perspective to sift through it and see the most important errors. Having an error.txt with the most recent issue is the best approach for now. A bug tracking system would be nice to have; we'd probably want it to be opt-in (for automatic), or on a case-by-case basis, along with some method to strip identifying information.

benthayer commented 3 years ago

This thread was speculative in terms of what we think will be useful. It's better to wait until we know how we can make something useful, so I'm closing this.