I must be overlooking something, because I don't think that you would see the effect you are expecting:
> From: Paul Smith <[email protected]> > > 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. Dale -- 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 to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
