Comments (6)
I love the idea, thanks for the suggestion @thisismygitrepo.
Finding the "right" algorithm will be a trade off between complexity-accuracy and the solution will inherently be opiniated.
Personally, I'm okay with it being a rough estimate as long as the logic is sound and well-documented.
I believe it shouldn't necessarily be part of the onefetch project, but a completely separate crate/project that maybe onefetch can add as a dependency.
For the sake of simplicity in review, integration, and testing, we could start by incubating it within onefetch for the first iteration, and then later on extract it into its own crate. Alternatively, we could begin with it as a separate crate from the outset. Both approaches are feasible.
@thisismygitrepo If you're up for it, feel free to give it a try!
from onefetch.
Fun idea! First we'll probably want a utility in place to detect files that are generated or vendored, so that committing e.g. dist/*
or bootstrap.min.js
won't incorrectly increase the calculated work time.
After that, I'd assume we'd get work from an estimated lines of code per hour or bytes per hour (there are pros and cons to each). The simplest way would be to check the current files, but this won't take deletions into account. If a project is rewritten, we'd miss a lot of the work hours! The most accurate way would probably be to compare all the deltas of the commits discoverable in the current branch, but this will be more expensive and time-consuming.
from onefetch.
Thanks for expressing interest. That's a lot of ideas for first comment. We can start simple by hardcoding the exclusion of cache files and generated code. There are good tools that identify such files for all types of projects, e.g., kondo
.
This repo has implementation. The README refers to 30
lines of code algorithm with decent explanation.
I tried installing it but it didn't work.
This one worked but it vastly overestimated the time.
The unreasonable numbers are probably due to the caveats that you discerned in your first line of reasoning.
At the end of README, the author refers to the first repo as source of inspiration and quotes the overuse of dependencies (js libraries) in it as a reason to hack together a standalone binary in golang.
from onefetch.
🤔 As I understand it, both of those use the time between commits to estimate the time worked. TBH I think this is a mistake. For example, I will often use git add -p
to select the changes I want and ignore the changes I don't want for a commit, commit them, then repeat until I've committed all my changes. This practice means that I might have spent a significant amount of time, but my commits would all be grouped into the span of a few minutes. This could lead to a significant underestimation of time spent. One could also make these tools significantly overestimate time by simply making a small commit that took 5 minutes to write, waiting an hour, and making another small commit. The actual time spent might just be 10 minutes, but, AFAIK, these tools would consider that an hour of work.
IMO any tool that estimates time worked in a git repository would need to take code size into account (lines of code, file size, or something else). A quick Google search told me that the average developer writes 20 lines of code per hour, so that might be a good starting point.
from onefetch.
I see.
In general, you seem to have many reservations about any algorithm based on certain git-committing behaviour as it cracks with repos developed by coders with different behaviour.
I like the irreducibly simple algroithm of dividing numbe of lines by 20 to get number of hours. I just used the provided number of lines
in onefetch
on one of my repos and I got 380 hours. This is a reaonsable estimation IF I wrote it as is with zero change.
- Step 1 from here: find total number of lines including all the changes (its like integration in maths, start from first commit, then add up changes lines time).
- Step 2: I propose a different factor that incorporate the size of the repo. The factor of 20 lines per hour could be reasonable the project is small. But when the project grows in complexity, you spend way more time observing tthe consequences of any small change on the overall behaviour.
from onefetch.
- I propose a different factor that incorporate the size of the repo. The factor of 20 lines per hour could be reasonable the project is small. But when the project grows in complexity, you spend way more time observing tthe consequences of any small change on the overall behaviour.
I'm glad you're thinking about this! For the sake of a reasonable estimate, I wonder if "development time" should be reimagined as "coding time" -- i.e. the actual time spent writing code for the project. "Development" is a broad subject, and can include responding to issues, reviews, planning, etc.
🤔 I think that calculating time spent can be a serious undertaking with a lot of code complexity. Additionally, it would have a lot of utility outside of this project. For this reason, I believe it shouldn't necessarily be part of the onefetch project, but a completely separate crate/project that maybe onefetch can add as a dependency. @o2sh Thoughts?
from onefetch.
Related Issues (20)
- Translate `README.md` to German 🇩🇪
- Parse .gitattributes HOT 1
- GPL-3.0-or-later licenses wrongly reported as GPL-3.0-only HOT 4
- Cannot load git config from non-standard paths when installed from `snap` HOT 18
- I can't install the new version: v2.20 HOT 2
- Installer hash does not match HOT 6
- Bare repository support HOT 6
- RUSTSEC-2024-0320: yaml-rust is unmaintained.
- Handle future commit datetimes in the future without panicking HOT 9
- Include a flag to replace the "circle" with a glyph from Nerd Fonts HOT 21
- Automatically detect if no programming language is present to show overview in data-only repository HOT 9
- Add CLI option to force URL format to http
- Churn computation sometimes hangs/deadlocks
- Churn includes bot commits when `--no-bots` option is provided
- Lua dark blue color make it hard to read HOT 2
- Wiki page "Images in the terminal" refers to incorrect command line argument HOT 1
- Can't build on Asahi Fedora Remix (m1 pro)
- Language request: Lean
- Language request: Typst HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from onefetch.