From: "Paul Smith" <>
To: <>
Sent: Tuesday, March 26, 2013 8:23 PM
Subject: [git-users] Reformatting vs. git blame

Hi all; please don't respond "just don't do that", because that's not an
option :-).

We are reformatting our codebase. Obviously we want to do this exactly one time, and be done. I have an automated tool that will perform this reformatting, which includes not just whitespace / indentation but also
adding braces and similar changes, so just ignoring whitespace is not
sufficient. I can script this so that it will redo the entire codebase
with one command, and the result is stable / reproducible.

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,

Is this user ID programmable? (see later)

 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.

Reformatting only the files that were modified on the branch is a little
better but still leaves the entirety of each modified file marked as
modified by a given user due to the reformatting, even if only one line
was changed.  Also not ideal.

What I really need is somehow to re-apply the changes from a branch on
top of the post-reformatted version, with only the actual changes
involved being noted as "new", not the reformatting.  However rebase
won't cut it because I need to apply the reformatting to the changes as
well, to avoid massive conflicts.

Maybe something like this:

    1. For each modified file on the branch:
             * Reformat it
             * Generate a diff between that version and the
post-reformat master version and save it as a patch file
             * Get rid of the local reformat
    2. Merge from master, forcing it to keep "theirs" so our branch is
       now the same as master.
    3. Apply the patches from step 1.  This _should_ be clean/no
    4. Commit.
    5. Continue working & merging, and when done merge back to master.

Would that work?  Am I missing something?  An easier way?

After updating your master with you script,
get developer to update their own branch, but as a "filter-branch", with their own username. They now have a corrected data set that can be rebased, or a format-patch set generated, that summarises their changes which should be apply-able upstream.

I presume you want any work-in-progress branch to be based on top of your newly reformatted master!

I'm not sure how to accomplish step #2.  I note that while "git merge"
has a "-s ours", there's no "-s theirs" which seems to be what I want.
I could reset the branch to the "post-reformat" tag then apply the
patch, but that is not a merge commit so there's a break in the history.
I don't know if this is significant or not.

Suggestions on how to accomplish the goal, and things to think about,
are appreciated!

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

Reply via email to