Follow replaced commits (created with `git replace`)

[julianneswinoga]

I don't think that onefetch respects commits that are replaced using git replace (https://git-scm.com/book/en/v2/Git-Tools-Replace). This is often used in large repositories where the history can be quite long, so for every-day development only a subset of the actual history is used. When a developer wants to see the entire history (for use with git blame or similar) they can use git replace to 'soft-change' the oldest commit in the repo with a separate branch with the complete history.

Reproduction steps:

$ mkdir project && cd project && git init .
$ echo "#include <stdio.h>" > file.c && git add file.c
$ git commit -m "Initial commit"
$ echo "// 2nd line" >> file.c && git commit -am "2nd commit"
$ echo "// 3rd line" >> file.c && git commit -am "3rd commit"
$ echo "// 4th line" >> file.c && git commit -am "4th commit"
$ git branch long_history HEAD^ # Create branch off of 3rd commit
$ git log --oneline --decorate
ebd4db1ff67 (HEAD -> master) 4th commit
e0eeb37cb45 (long_history) 3rd commit
587949b2eb8 2nd commit
2983aa7d71f Initial commit
$ echo 'Short history stops here' | git commit-tree 'HEAD~2^{tree}'
2ca3c4dd4e57edd0a70a7b3fed23f96c278b3764
$ git rebase --onto 2ca3 HEAD~2
$ git log --oneline --decorate master
70a1fa6fb0d (HEAD -> master) 4th commit
652667cd887 3rd commit
2ca3c4dd4e5 Short history stops here
$ git log --oneline --decorate long_history
e0eeb37cb45 (long_history) 3rd commit
587949b2eb8 2nd commit
2983aa7d71f Initial commit
$ git replace 6526 long_history # Here's the git-replace
$ git log --oneline --decorate master # Now, even though we're on master we still have access to the full repo history
70a1fa6fb0d (HEAD -> master) 4th commit
652667cd887 (replaced) 3rd commit
587949b2eb8 2nd commit
2983aa7d71f Initial commit
$ onefetch
                 ++++++                    User Name ~ git version 2.35.1
              ++++++++++++                 ------------------------------------
          ++++++++++++++++++++             HEAD: b71faf0 (master)
       ++++++++++++++++++++++++++          Created: a minute ago
    ++++++++++++++++++++++++++++++++       Language: C (100.0 %)
 +++++++++++++************+++++++++++++    Author: 100% User Name 3
+++++++++++******************++++++++:::   Last change: 36 seconds ago
+++++++++**********************++:::::::   Commits: 3
++++++++*********++++++******:::::::::::   Lines of code: 1
+++++++********++++++++++**:::::::::::::   Size: 55 B (1 files)
+++++++*******+++++++++:::::::::::::::::
+++++++******+++++++::::::::::::::::::::
+++++++*******+++:::::::::::::::::::::::
+++++++********::::::::::**:::::::::::::
++++++++*********::::::******:::::::::::
++++++:::**********************:::::::::
+++::::::::******************:::::::::::
 :::::::::::::************:::::::::::::
    ::::::::::::::::::::::::::::::::
       ::::::::::::::::::::::::::
          ::::::::::::::::::::
              ::::::::::::
                 ::::::

$ onefetch --version
onefetch 2.11.0

Note that the number of commits does not match what the actual repo has. All the other metrics don't follow the git-replace either (but you can't see in this example because it is short).

[spenserblack]

Interesting, I wasn't aware of this usage before. I'll need to look into this more, but my initial instinct is that your issue is happening in these lines (below), and that the root cause is how git2 determines if a commit is discoverable.

onefetch/src/info/repo.rs

Lines 52 to 65 in af3967f

	let mut revwalk = repo.revwalk()?;
	revwalk.push_head()?;
	let logs: Vec<Commit<'a>> = revwalk
	.filter_map(|r| match r {
	Err(_) => None,
	Ok(r) => repo
	.find_commit(r)
	.ok()
	.filter(|commit| !(no_merges && commit.parents().len() > 1))
	.filter(|commit| {
	!(bot_regex_pattern.is_some() && is_bot(commit.author(), bot_regex_pattern))
	}),
	})
	.collect();

[Byron]

Indeed, such object replacement is ideally done directly on the level of the object database, and gitoxide does that now. With the linked PR merged, this issue should be fixed. @cameronswinoga could give it a try just to be sure - building #635 should do the trick.

[julianneswinoga]

@Byron Yep looks good! Thank you so much! 😄