On Mon, Apr 24, 2023 at 12:21 PM Jeremy Morton <admin@xxxxxxxxxxxxxx> wrote: > > I'm surprised --follow isn't the default, actually... isn't the whole > point of detecting renames to allow content history to be tracked back > through renames? You can set log to --follow by default If true, git log will act as if the --follow option was used when a single <path> is given. This has the same limitations as --follow, i.e. it cannot be used to follow multiple files and does not work well on non-linear history. https://git-scm.com/docs/git-log#Documentation/git-log.txt-logfollow The reason it's not default is probably those limitations. > > Another one that jumped to mind for me is bisect. As rename-only > commits are liable to create broken builds, it should skip over them > to the 'content' commit. > I always find this to be the main dilemma. I try to make commits as discrete changes but it's not always possible with renames. Sometimes, renaming a file changes it so much that the rename detection doesn't work by default. There are also other problems that arise when reordering commits and changes in a feature branch. I've found that the safest thing is to split renames out into discrete commits and only do 100% renames.
