Ok. Perhaps you caught me at a bad day, but I have to say something now: I've put several days of my life into making sure that we have a consistent approach that everybody can work with, that addresses some very legitimate concerns we have about our IP tracking record, and that gave us a semi-decent compromise between ease of use and consistent/clean history. I facilitated discussions about this, tried to incorporate everyone's point of view, and wrote quite an extensive bit of documentation with clear step-by-step instructions on how to do things like squashing, including a thorough explanation of why we do these things this way.
And now, because I have asked you to manually squash that one PR, you dismiss it all with an airy "meh, too hard - let's just do what I like instead". I don't mind reconsidering our approach, but frankly I find this just a little insulting.
<deep breath>
For reasons of keeping the git history at least semi-navigable, we should have a somewhat consistent merge strategy. Not "you rebase if you want, them over there can squash-and-merge, and I'll just merge-commit everything because I like it like that" - that way madness lies. And just to be clear: I am not advocating merge-commits because I personally prefer merge-commits, I'm advocating merge-commits because it is the simplest consistent approach that we can ask everybody to adhere to.
So let's consider squash-and-merge again as an alternative, because that is clearly the option most of us prefer (including myself): it would be simpler than manual squash + merge commits, if only it wasn't for that pesky problem with authorship.
Github uses the author of the pull request as the author field on a squash and merge commit. I'm not 100% sure on this but it looks as if it uses an author account's primary e-mail address, and not the e-mail address associated with a particular repo. Also: if an author has configured their e-mail addresses to be private, it uses a "noreply.github.com" address.
The "noreply.github.com" thing I can live with - the ECA check probably barfs on it but we can ignore that, and the Eclipse EMO has already indicated that they're not too worried about this as long as the signoffs are still in place (which they normally are when you use squash and merge). The primary email thing is a bigger concern though. It may have legal repercussions (yes, I know it sounds stupid, but it's true).
This is not something that only affects third party contributors: it could just as easily happen with core committers, including myself. I recently had to change my primary Github account address to my work address, and frankly I have no idea if that will affect any PRs that I merge with squash-and-merge on the RDF4J repository (and no, it's not ok for me to have my work address linked to RDF4J commits). It's not something you can see before you click squash and merge, because Github doesn't show what it will use as the author address.
So: if we want to find a way to re-enable the use of squash and merge, we need to spike this, figure out what happens with the author / committer field in various cases. It's severely under-documented unfortunately.
Jeen
On Tue, 19 Jan 2021, at 18:40, Håvard Ottestad wrote:
Hi,
Wanted to bring up the discussion again.
We’ve gone full circle, just like everyone does. We’ve tried mono repo and multiple repos. We’ve done merge commits, squash and merge and now we are doing local squash (rebase) and then merge commit.
I think it’s all a bit too strict for the sake of very little benefit. The absolutely biggest benefit for me of our git history is to be able to git blame a couple of lines of code to see where they came from and why they are the way they are.
A lot of the older code though all you get is some generic commit by Jeen for when the project was moved or renamed or something like that.
I would like to advocate for a bit more Wild Wild West and a bit less ordnung must sein. Essentially, reactivate the git squash and merge button for smaller PRs by committers. Live with the regular, old fashioned merge approach. And for those that really want to, they can rebase and merge and create a nice clean git history.
Cheers,
Håvard
_______________________________________________
rdf4j-dev mailing list
_______________________________________________
rdf4j-dev mailing list
