A report describes a repository as it is now. That is the wrong shape for the question people actually bring: what did this person do between these dates, at that job, on that project.
--since and --until bound the commit side, and surviving is always taken at one ref. So a person whose code was later rewritten reads as having done little, and a person who joined last month sits beside four years of history with no way to say so.
What to build. A report about a window: what was done in it, how much of it survived to the end of the window, and how much survives today, with all three stated separately.
Done when
- The window is carried in the report and in the hash, so a reader cannot mistake a bounded report for a whole-history one. A report that hides its window is a way to mislead, and this is the first thing to get right.
- Surviving lines are computed against a stated ref, and the report says which. The difference between "survived to the end of your tenure" and "survives today" is the interesting number here and both belong in the output.
- Figures that lose meaning under a window say so rather than printing something. A cadence over three weeks is not a cadence.
- The README gains the sentence a reader needs: work that did not survive was still work, and a low survival share over a window is not a verdict on it.
Out of scope. Inferring employment dates from the history. The window is supplied by the person, and the report says it was supplied rather than derived.
This is the feature that makes the tool usable for the case it was built for. Somebody proving four years at a company that has since rewritten the codebase currently gets a report that undersells them, and the honest fix is to measure the period rather than the present.
Taking this on: comment and it is yours. Nothing here needs permission first, and a partial answer beats a perfect one that never lands.
What gets a pull request rejected here: a change with no test; a new runtime dependency; or a number written into a README or a document that did not come from a run somebody else can repeat.
A report describes a repository as it is now. That is the wrong shape for the question people actually bring: what did this person do between these dates, at that job, on that project.
--sinceand--untilbound the commit side, andsurvivingis always taken at one ref. So a person whose code was later rewritten reads as having done little, and a person who joined last month sits beside four years of history with no way to say so.What to build. A report about a window: what was done in it, how much of it survived to the end of the window, and how much survives today, with all three stated separately.
Done when
Out of scope. Inferring employment dates from the history. The window is supplied by the person, and the report says it was supplied rather than derived.
This is the feature that makes the tool usable for the case it was built for. Somebody proving four years at a company that has since rewritten the codebase currently gets a report that undersells them, and the honest fix is to measure the period rather than the present.
Taking this on: comment and it is yours. Nothing here needs permission first, and a partial answer beats a perfect one that never lands.
What gets a pull request rejected here: a change with no test; a new runtime dependency; or a number written into a README or a document that did not come from a run somebody else can repeat.