Lorem ipsum dolor sit amet, consectetur adipiscing.
@tallamjr How is your git fu with this kind of problem?
A git log --follow -p -- project_management/personas.md will do the trick.
The main flag is --follow:
--follow
Continue listing the history of a file beyond renames (works only for a single file).
and then -p to show the "patches" changed.. -- to say not more flags from this point.. and finally the path to where the current file is located..
Hope this helps.
Thank you @tallamjr. Let me try this and update.
To answer your second question @malvikasharan, did you use mv when you moved the file, or git mv?
I used mv and I see the error in that! The git log and blame keeps the history (thanks for the hat tips @tallamjr) but GitHub doesn't after mv :(
馃槩That's disappointing. I imagine to GitHub, this looks like a "new" file?
so so disappointing, especially because the blame button knows who to blame for that (I am looking at me right now!). It's useful to add this in the contributing guideline for best git practices when moving locations of the file.
It's useful to add this in the contributing guideline for best git practices when moving locations of the file.
Also the git chapter? :sweat_smile:
Judging from 906620a the file was moved properly. It's not being treated as a new file. The problem is that the GitHub web interface doesn't expose the --follow functionality discussed above.
It looks like many people want GitHub to support --follow judging from threads like these:
It sounds like GitLab already has this feature.
Thanks for those resource @pdurbin and clarifying the feature issue.
Most helpful comment
Also the git chapter? :sweat_smile: