This is day 21 of my Git Tips and Tricks Advent Calendar. If you want to see the whole list of tips as they're published, see the index.
Update: Alex Tercete provided a
helpful correction about the
merge -Xrenormalize command; I've updated
this with a correction.
This month I've given a few tips and tricks that I think are important - for example, getting your line ending configuration right. But a lot of these settings require you to get them set up in the initial commit, ideally before you start adding content to your repository.
But development - like most of life - isn't always so simple. What if you've
already committed changes? And you've been using
inconsistently, instead of using a
.gitattributes? So you've got a mix
of line endings in your repository?
Thankfully, that's an easy fix.
- Add your
.gitattributesFirst things first, get your
.gitattributesfile set up correctly, so that line endings are "normalized", that is, converted to Unix-style (LF) line endings when you add files to your repository.
git add --renormalize . && git commitIt's that simple: this will go through every file in your repository, and "renormalize" them: that is, re-add them to the repository with the line ending configuration that you specified in your
.gitattributes(in step 1).
So now any files that were, erroneously, checked in with Windows-style line endings will now be "renormalized" to have Unix-style line endings.
A word of warning, though: this might cause big ol' merge conflicts! Since you've changed every line of some files, to have new line endings, any change that somebody else has made in another branch is almost certain to conflict.
Unfortunately, this will require a bit of manual intervention. You have two choices, as the author of the pull request: merging with or rebasing onto the master branch, with the renormalize option:
git merge -Xrenormalize --no-commit master [fix any conflicts as necessary] git add --renormalize . git commit
I previously indicated that
git merge -Xrenormalize was enough; it's not,
as that will only affect the way automerged or conflicting files are dealt
with. It won't renormalize any new changes that you've made in your branch.
So the best way to do this is to do the merge with a
no-commit option, fix
up any conflicts that might exist, and then do a
git add --renormalize before
committing the merge.
(Thanks to Alex Tercete for the correction.)
git rebase -Xrenormalize master
Whether you prefer a merge or a rebase strategy, once you've integrated the changes, you can push them back up in the pull request branch. The pull request can now be automerged into the master branch, and will have the correct line endings.