How to handle widespread code format changes in a git repository

views:

311

answers:

+13 Q:

How to handle widespread code format changes in a git repository

+4 A:

I don't know how best to deal with some of the more invasive changes you're describing, but...

The -w option to git blame, git diff, and others causes git to ignore changes in whitespace, so you can more easily see the real differences.

Phil 2009-12-01 06:57:52

And `-M` / `-C` options to `git diff` and `git blame` make it follow renames and copies; in the case of `git blame` also moving and copying of fragments of code across files.

Jakub Narębski 2009-12-01 15:40:59

Ooh thanks, I've just been annoyed by this for a while in one of my projects. Also, I feel bad for upvoting you since you had 1337 rep :/

Ibrahim 2009-12-31 01:28:49

+3 A:

I would recommend making those evolutions one step at a time, in a central Git repo (central as in "public reference for all other repositories to follow):

indentation
then reordering methods
then renaming
then ...

But not "indentation-reordering-renaming-...-one giant commit".

That way, you give to Git a reasonable chance to follow the changes across refactoring modifications.

Plus, I would not accept any new merge (pulled from other repo) which do not have applied the same refactoring before pushing their code.
If applying the format process brings any changes to the fetched code, you could reject it and ask for the remote repo to conform to the new standards first (at least by pulling from your repo before making any more push).

VonC 2009-12-01 07:14:45

We've been leaning that way too. As for not accepting patches unless their rebased against the post-transform code, that isn't really a viable option; "rebasing" across such a change would amount to manually most/all retyping the changes (think how the inevitable merge would go if most lines had been changed).So we considered making them run the refactor tool themselves, but since this process could be automated why not run it ourselves on patch acceptance rather than making them learn it, and adding an extra hurdle on contributions?

MarkusQ 2009-12-01 16:08:21

@MarkusQ: I agree on the principle, but just to be sure: I wasn't talking about a mandatory "rebase" to be done on the client side, only about a mandatory "reformat" to be done by the client before his push (reformat checked in a hook on the server side by re-applying the same reformat and checking the result is the same than the file received). That will avoid many merge conflicts when those same clients fetch the central public repo changes and rebase their work on top of it.

VonC 2009-12-01 16:57:33

You will also need a mergetool that allows agressive ignoring of whitespace. p4merge does this, and is freely downloadable.

krosenvold 2009-12-01 09:34:13

Thanks for the downvote; I'd be curious to know why ?

krosenvold 2009-12-02 08:04:19

Probably because the question is about git and how it will handle the changes, and not necessarily other tools to for helping with the work.

hlovdal 2010-01-25 11:32:51

ansaurus

tags:

views:

answers:

How to handle widespread code format changes in a git repository

related questions