I must be overlooking something, because I don't think that you would
see the effect you are expecting:
> From: Paul Smith <p...@mad-scientist.net>
> We accept that "git blame" across the reformat will not be useful. I'm
> going to lay down a label right before the reformat, so people can use
> that to trace back git blame before it happened. I also will use a
> special "code reformat" user ID for the reformat commit, so that it's
> obvious in "git blame" when lines were changed due to the reformat, vs.
> being changed afterwards. That's all fine.
> My issue is how to handle unmerged developer branches, without breaking
> my "git blame" results.
> Having developers reformat their branches works and gives an easy merge
> post-reformat, which is nice, but it also blows away the "git blame"
> results: basically every branch merged in will look like that user
> changed the entire tree. That's not so good.
I do not see why merging a branch in will cause all lines in the file
to be marked as changed by the user who did the merge (from whose
branch the merge was done). Assuming the reformatting in the master
and the reformatting in the developer's branch is exactly the same,
when the developer goes to merge his changes back into master, only
lines that he changed "for real" will be different -- lines that were
changed only by reformatting will be changed in exactly the same way
in both sources, and presumably "git blame" does not consider them to
be changed by the merge.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.