3 ms·
You don't need to blame every file[1]. Use `git rev-list` to find your oldest commit: git rev-list --reverse --date-order HEAD | head -1 # or git rev-list
by js2 2y ago
You don't need to blame every file[1]. Use `git rev-list` to find your oldest commit:
git rev-list --reverse --date-order HEAD | head -1 # or
git rev-list --reverse --author-date-order HEAD | head -1
To see the files in that commit:
git ls-tree -lr <commit-id>
To see a particular file:
git show <commit-id>:/path/to/file # or
git cat-file -p <commit-id>:/path/to/file
[1] Caveat: I suppose this doesn't account for files which no longer exist or that have been completely re-written.
https://git-scm.com/docs/git-rev-list https://git-scm.com/docs/git-rev-list
https://git-scm.com/docs/git-ls-tree https://git-scm.com/docs/git-ls-tree
https://git-scm.com/docs/git-show https://git-scm.com/docs/git-show
https://git-scm.com/docs/git-cat-file https://git-scm.com/docs/git-cat-file
https://git-scm.com/docs/gitrevisions https://git-scm.com/docs/gitrevisions
- roetlich 2y ago> I suppose this doesn't account for files which no longer exist or that have been completely re-written. But... that's the point of this? Finding the initial commit is not nearly as fun as looking at the oldest code that is still running.
- kazinator 2y agoYes, your caveat is correct: it's possible that none of the lines present in your oldest commit have survived into the current head commit of your main branch. Not sure how the article's algorithm deals with renames. If a file being renamed as a deletion and addition, then that conceals the age of the lines.
- js2 2y ago> Not sure how the article's algorithm deals with renames It's relying on `git blame`'s default behavior which is: "The origin of lines is automatically followed across whole-file renames (currently there is no option to turn the rename-following off). To follow lines moved from one file to another, or to follow lines that were copied and pasted from another file, etc., see the -C and -M options."