Open seanmakesgames opened 4 months ago
I'm personally on the fence about this -- yes, using merge commits as the PR merge method would prevent issues regarding branch reuse; but you shouldn't really be reusing PR branches anyway.
And I just know someone (probably me) is going to end up caring too much about the history in a PR if it doesn't get squashed away at the end. (I mean, hell, I sometimes do that with the current squash method. Still working on not doing that.)
On the other hand, minus doing a revert
or a blame
, we probably aren't going to be doing much with the history in this repository anyway.
I do also think it's worth mentioning that people are going to end up getting merge conflicts at some point if, say, we merge a PR that modifies a file their PR also modified. I don't really know how resolving that compares with branch re-use issues in terms of difficulty for a new user; but that is something we have to deal with regardless of how we proceed here.
I'm personally on the fence about this -- yes, using merge commits as the PR merge method would prevent issues regarding branch reuse; but you shouldn't really be reusing PR branches anyway.
The point here is that we are setting ourselves directly up for this case every time a contributor decides to use the same branch -- which will be a high likelihood, because we have a lot of people who are new to source control and new to git. In our current model, there is 0-way to not get conflicts when you reuse a branch after merge without extra work on the contributors part.
I do also think it's worth mentioning that people are going to end up getting merge conflicts at some point if, say, we merge a PR that modifies a file their PR also modified. I don't really know how resolving that compares with branch re-use issues in terms of difficulty for a new user; but that is something we have to deal with regardless of how we proceed here.
yes. conflict is inevitable.
problem
Non-merge commit merge methods are less forgiving to new users of source control. Branch conflicts are some of the hardest problems in source control. This creates higher barrier to entry for contributors.
context
I don't believe that cleaner source history is worth this tradeoff in accessibility. Discuss.
_Originally posted by @seanmakesgames in https://github.com/comcode-org/hackmud_wiki/issues/403#issuecomment-2027391523_