-
Notifications
You must be signed in to change notification settings - Fork 277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle future commit datetimes in the future without panicking #1306
Comments
I'm that colleague |
But I like that "time travel" achievement 😢 😆 But you're right that we could handle this more gracefully. I think that most people don't pay attention to the commit time, so even if it was an unreasonable value like in the year 3000 it could still get merged in. And if that happens the repo is basically unusable by onefetch unless a maintainer rewrites the history to fix the commit date. So overall we should change this from a panic to a warning message so that at least onefetch can display the other stats, and one unexpected time getting accidentally merged in doesn't "break" the whole repo for onefetch. Besides the panic, I'm also worried that we're dropping the timezone offset somewhere, which can cause this issue. Do both of you (@OsiPog and @MalteT) live in different timezones, and can you confirm that your system times are correct? |
Actually, we live in the same time zone and I can confirm that my system time was in fact incorrect. So I just caused this issue by commiting with my system time being in the future. |
I think we did have a timezone issue, anway 😆 2a3707e Regardless of who or what caused the issue, I don't think anybody wants to rebase the commit history to fix the commit times just to get |
Labeling this as an enhancement instead of a bug since the panic was intended behavior. |
Or I'm not familiar with the code base, but if the change is not too involved I could assemble a PR :) |
Oh, I like that better, actually! All you need to do is filter out commits where the commit time is greater than now. But to do that some refactoring might be needed to avoid recalculating "now" in multiple places. Ideally |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Coming back to this, I think it should be pretty easy to implement. I'm just making a quick comment without checking the codebase, but I think that all that needs to happen is:
Footnotes
|
Duplicates
Current behavior 😯
If the commit time is in the future, onefetch crashes.
Expected behavior 🤔
It should possibly handle the case or fail gracefully. The crash report blames this on me, but my system time is okay and I don't have much influence over my colleague's system time.
Steps to reproduce 🕹
Have the most recent git commit in the future and run
onefetch
Additional context/Screenshots 🔦
Possible Solution 💡
No response
Thanks for your awesome work!
The text was updated successfully, but these errors were encountered: