>You can feed a set of revisions to git-blame with the "-S" option, but I >don't offhand know how it handles diffs (I think it would have to still >diff each commit against its parent, since history is non-linear, and a >list is inherently linear). You might want to experiment with that.
>Other than that, you can play with git-replace to produce a fake >history, as if the deletion never happened. But note that will affect >all commands, not just one particular blame. It might be a neat way to >play with blame, but I doubt I'd leave the replacement in place in the >long term. > -Peff Ah I see. Will try git-replace. Thanks! On Fri, Dec 7, 2018 at 11:29 PM Jeff King <p...@peff.net> wrote: > > On Fri, Dec 07, 2018 at 01:50:57PM -0800, biswaranjan panda wrote: > > > Thanks Jeff and Bryan! However, I am curious that if there were a way > > to tell git blame to skip a commit (the one which added the file again > > and maybe the one which deleted it originally) while it walks back > > through history, then it should just get back the > > entire history right ? > > Not easily. ;) > > You can feed a set of revisions to git-blame with the "-S" option, but I > don't offhand know how it handles diffs (I think it would have to still > diff each commit against its parent, since history is non-linear, and a > list is inherently linear). You might want to experiment with that. > > Other than that, you can play with git-replace to produce a fake > history, as if the deletion never happened. But note that will affect > all commands, not just one particular blame. It might be a neat way to > play with blame, but I doubt I'd leave the replacement in place in the > long term. > > -Peff -- Thanks, -Biswa
