On Mon, Apr 17, 2017 at 2:36 PM, Urs Thuermann <urs@xxxxxxxxxxxxxxxxx> wrote: > Igor Djordjevic <igor.d.djordjevic@xxxxxxxxx> writes: > >> For both cases (renaming and splitting), would using `--find-copies` >> work for you? Perhaps with some low threshold value to start with, if >> the default one yields no results. >> >> If interested, adding `--name-status` to the mix will show similarity >> percentage between old and new file(s). > > I didn't know --find-copies and --name-status and I've now looked them > up in the doc. Looks interesting but instead of looking for > similarity it would be better IMHO if there was a command "git cp" and > that "git mv" and "git cp" were recorded in the history somehow. > > I'm still using CVS (and SVN in some few cases) but considering > changing to git. There are some things, however, that I can do more > easily in CVS (like editing CVS ,v files instead of git commit > --amend) and I need to learn more git before I want to change (and > migrate existing repos). > > urs Unfortunately I don't have a ready link to the message, but there is a very good post from early on in Git's development where Linus explains why Git does not store rename and copy information in the history. Essentially, it's because that information can be regenerated from the blobs later, and you can get better information with better algorithms and you don't bake the original implementation into the history forever. Thanks, Jake