On Mon, Dec 10, 2018 at 01:33:18PM -0800, Elijah Newren wrote: > Hmm...sure, if the file is deleted on the only relevant branch through > history...but what if there were another branch where it weren't > deleted? What does git blame do then? > > In other words, do NOT restore the file as biswaranjan suggested, but > instead restore it this way[1]: > > git checkout -b keep-foo $REVISION_BEFORE_FOO_DELETED > git commit --allow-empty -m "We want to keep foo" > git checkout A > git merge --no-commit keep-foo > git checkout keep-foo -- foo.txt > git commit > > > Now, when you run > git blame foo.txt > > blame should notice that foo.txt didn't exist in the first parent > history on A, so it won't bother walking it to find that at some point > foo.txt did exist there. Instead, it'll walk down the second parent > and follow its history, where it should keep walking back and show all > the old changes...right? Or did I mess up my testcase and > misunderstand something somehow? Yeah, I think that should work, and is a clever way of representing in the actual history graph what you're we're trying to express. And it shouldn't have any real downsides. -Peff
