git am/format-patch: control format of line endings

Question

I created a patch from three commits using

git format-patch <revision_three_commits_ago>

This creates three patch files that I mailed from my notebook and read the mail on my desktop computer (both are Windows boxes).

When I do now

git am --3way --ignore-space-change *.patch

the patches apply, but I don't get the same SHA1 IDs for the commits. Searching a bit in the patched files, I found that the modified lines on my desktop computer end with LF, whereas the modified lines on the notebook (where I created the patch) end with CR LF.

So, my first thought was to call git am without --ignore-space-change, but this gives me an error (patch does not apply).

How could I tell git format-patch or git am about how to handle the line endings (msysgit 1.7.4)?

Do I really have to take VIM and change the file format from UNIX to DOS before I can apply the patches?

---

EDIT: Not even modifying the patch files with VIM helps: I thought, set ff=dos and a :%s/^M//g would help, but it doesn't!

In my opinion, applying a patch should result in exactly the same content and also the same commit hash like I pulled from the other repo where the patch was created. Am I thinking wrong about that?

Answer 1

After playing around with various options (core.autocrlf, core.eol) I found that using

git am --keep-cr

does the trick (but causes a warning about trailing whitespaces).

No manual editing of the patch file or other dirt is neccessary.

But, (of course) the hash is different as described in nikai's answer... Thanks to nikai for pointing me to the hash stuff.

In my notebook-desktop-scenario, I wanted to transfer some changes offline from notebook to the desktop computer, but the repos should not diverge nor should the same commit occur twice when I applied the patch on the desktop and then do a git pull desktop from the notebook.

To achieve this, I did the following:

1. On the desktop, apply the patch as described above using git am --keep-cr ...
2. On the notebook, to a git pull desktop, which leads to the situation that each commit introduced by the patch occurs twice (once for the original notebook commit, once for the patched and pulled in desktop commit)
3. Now (being on the master branch of the notebook), issuing a git rebase desktop/master leads to No changes -- Patch already applied message and kicks out the original notebook commits replaced by the desktop commits