This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author benjamin.peterson
Recipients benjamin.peterson, erinspace, gregory.p.smith, martin.panter, python-dev, r.david.murray, serhiy.storchaka
Date 2016-06-03.05:31:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1464931899.2472782.626653321.3D41C695@webmail.messagingengine.com>
In-reply-to <1464917292.69.0.61037900275.issue27185@psf.upfronthosting.co.za>
Content
On Thu, Jun 2, 2016, at 18:28, Martin Panter wrote:
> 
> Martin Panter added the comment:
> 
> FWIW I doubt Git is any better at this than Mercurial:
> <https://github.com/python/cpython/blame/master/Lib/test/test_string.py#L190>
> 
> Git can automatically pick up file renames and copies when analysing the
> history, but has no special metadata for this. I understand Mercurial is
> the opposite (has metadata, but at least by default does not pick up
> copies and renames from the history). Perhaps that is what Benjamin was
> thinking of. I understand Git will only pick up movements of the majority
> of a file, not parts of files (unless something has changed recently).

git blame -C works quite well in my experience for detecting moved lines
of code.

In general, I think we shouldn't be afraid to reorganize code for fear
of breaking "VCS" history. The tools will catch up. (I think they
largely have already.) At worst, one must manually "follow" the move of
some code through history.
History
Date User Action Args
2016-06-03 05:31:42benjamin.petersonsetrecipients: + benjamin.peterson, gregory.p.smith, r.david.murray, python-dev, martin.panter, serhiy.storchaka, erinspace
2016-06-03 05:31:42benjamin.petersonlinkissue27185 messages
2016-06-03 05:31:42benjamin.petersoncreate