Hi Valdis, > "git mv" has you covered.
OK. > "foo_del.c has merged with foo.c in the next." > > Best practice here is to generate a commit that *only* does > the merge (plus any #include surgery, etc to make a clean compile), > and explain it was a code migration in the commit comment. Right. I wonder if git-mv(1) adds meta-data to the pending commit, and if so does that survive a merge of another commit that also moves to the same destination file. I'm guessing not as it would otherwise multi-parent graph of the destination file that I'm after. On a related note, I'm planning on pushing my current one-commit-per-new-foo.h as that way any dead ends in following `git blame', etc., will end with a small commit that makes clear where to pick up the trail. The alternative is to rebase and squash them all into one honking "empty h/prototypes.h". If anyone has good reasons why that's preferable, let me know. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
