On Tue, 2013-03-26 at 22:30 +0000, Philip Oakley wrote:
> From: "Paul Smith" <p...@mad-scientist.net>
> Sent: Tuesday, March 26, 2013 9:11 PM
> > On Tue, 2013-03-26 at 20:46 +0000, Philip Oakley wrote:
> >> > 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,
> The key point here is that this script should be able to record the 
> corrected tree as though it is a simple 'commit --amend' so that the 
> 'User' can either be your special "code reformat" user, or it can be the 
> developer.

Hi Philip; I really appreciate your assistance.  Unfortunately I've yet
to need to delve into some of the more advanced features of Git.  I've
used commit --amend of course, but I'm having a bit of trouble putting
everything together based on your comments.

> The key is to ensure the script can be applied as a `git filter-branch`, 
> and that it can maintain the developer's user name.
> Thus every commit on the developer's branch will be reformatted "by the 
> developer", so that:
> a) they can rebase their branch to match your desired start point and
> b) when their branch is merged it will slot in nicely

I've read the man page on filter-branch and it seems to be somewhat
applicable.  But I don't quite see how it all fits together.

For example I can see that I can use filter-branch to go through a list
of commits and apply my reformatter to each one.  But I'm not sure how
that solves the authoring problem: doesn't that still show the first
commit (where the first reformat was performed) as all modified by the
current user?  I can see that I can change the user by modifying the
environment inside the script, but that would (from what I see) make ALL
the changes in the commit, including the diffs, authored by the
reformatter user account.

The process I was considering for each non-master my/branch was:
     1. Check out my/branch
     2. Merge up to the master commit just before the reformat
     3. Reformat the code on my/branch (don't commit)
     4. Generate a patch from the master commit just after the reformat
     5. Throw away the local reformatting changes from step 3
     6. Reset my/branch to the master commit just after the reformat
     7. Apply the patch
     8. Commit to my/branch
     9. Proceed with development as normal

This is like a squashed merge and I lose the commit history for the
branch, so there are downsides.  Also as before, how best to accomplish
step #6 is not clear to me.  But it appears to maintain the "git blame"
results I'm hoping for and avoids massive changes in blame as these
"reformat straddling" branches are merged back.

Can you give something like the above level of detail for the process
you suggest using filter-branch?  It doesn't have to be exhaustive: I
can easily handle the scripting once I understand the process.

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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to