Re: [rdf4j-dev] Git history and merging - again

["Jeen Broekstra" <jeen@xxxxxxxxxxxx>]

On Tue, 19 Jan 2021, at 23:31, Håvard Ottestad wrote:

I did try to rebase it. But just on the first commit I got 7 merge conflicts for files I hadn’t even changed.

Fwiw on another look at that PR, I don't think it is really necessary to squash it, after all: there's only few commits and they're all meaningfullly commented - I think I mistook the merge commits in there for commits missing an issue number.

That said, (and I realize it's after the fact) I still don't see why you find it so hard to use rebase instead of merge to keep your feature branch in sync. It isn't hard. I've switched to it. Other contributors seem to have little trouble with it. This is what annoyed me about your mail initially - I got the feeling that you weren't really trying. Perhaps that's unkind of me but I hope you understand my frustration too: I put a lot of energy in discussing and documenting this, and making it as easy as possible. It's not nice for me to then hear you say it's "too strict" and "completely unnecessary". 

If it really is that dififcult and frustrating though, let's see what we can do to make it less of a hurdle.

My experience tells me that using effort on these things is not worth it.

If we want the history to be as compressed and simple as possible we should use the squash and merge button for those 99% of the cases. We will lose a lot of value though. Since that bug fix commit in the middle of that medium size PR gets lost next time someone wants to figure out why some strange code is kinda funky.

That is actually an argument for sticking with merge-commits, and perhaps being a bit less trigger-happy on the manual squashing. 

 

But if eclipse says that they don’t minI'md the email getting a bit mucked up for merges, then why should we. The signoff will still be there.

 

Just to be clear: Eclipse find an occassional noreply.github.com address slipping in acceptable. They (and me as well) are most definitely not ok with the author address changing to a different address than what they have on the ECA record (e.g. bob@work.example on the PR merge when bob only signed the ECA for bob@personal.example) just because bob has their account configured that way. And like I said: you can't see this in advance. That's the problem.

I think having more choice is better. 

The reason I keep trying to pick one strategy is that I'm trying to keep things simple and consistent. A git history that uses a single strategy is easier to read. Having both options enabled will inevitably lead to someone picking the wrong one at some point (perhaps not the end of the world, but still..).

But if you're saying we should use more individual discretion, then fine: we can of course enable both merge-commit and squash-and-merge, and use each in diffferent situations: squash and merge on big PRs with lots of commits that we want to squash where we know the author is correctly configured, merge commits on everything else (that will mean most third party contributions), occassional manual squashing/rebasing if the situation demands it (perhaps only if there are mulitple commits with unclear messaging in there). 

Jeen