From: "Paul Smith" <[email protected]>
To: <[email protected]>
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
conflicts.
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!
Philip
--
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.
