Merge option on PRs

[tim-schilling]

@matthiask which merge option do you use when merging PR's. I like a linear history, but I'm not a fan of GitHub putting me as a co-author on the changes. For example, #1786 had 6 commits, but now I'm associated with them.

[matthiask]

@tim-schilling I'm switching back and forth; if a pull request contains many fixup commits I'm using the squash option; if it's worth preserving the history I'm sometimes going for the rebase button or even for the merge. Sometimes I'm even checking the repository out locally so that I can preserve the committer if it's a fast forward.

I do not have a problem with merge commits, I just do not like repeated merges or criss cross merges too much. The main problem with merge commits in my opinion is that sometimes old files creep back up if a fixup has been manually ported to the long living feature branch. In this case it's safer to squash.

But, I really like attributing work, so in general I try to preserve the authorship and committership if it's possible and if it makes sense. I like that I could make my more recent contributions to Django under my name. A "thank you" note in the commit message is nice too of course, but the author field gives me more warm feelings.

Sorry for the long winded and unclear answer. I don't have a clear opinion either way. I try to find the sweet spot between preserving authorship and less work for me.

Screenshot from work :)

[tim-schilling]

Sometimes I'm even checking the repository out locally so that I can preserve the committer if it's a fast forward.

Alright, this is what I was doing, but stopped for the convenience of GitHub's one click button. But I was sad that I removed @living180 as the committer of a number of commits.

It sounds like we're on the same page and I simply need to use my computer to merge things, not my phone.

Thank you for the insights!