search

comcode-org / hackmud_wiki

https://wiki.hackmud.com/
Other
13 stars 21 forks source link

non-merge commit merge methods are less forgiving to new users of source control #404

Open seanmakesgames opened 4 months ago

seanmakesgames commented 4 months ago

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.

Looks like you might be using the same branch as before-- because we use the 'squash' merge method, the main branch doesn't understand that all of these changes were already merged and thinks that they are in conflict. (this is why the files changed tab looks full of stuff that's already been merged)

To sort it out, re-sync your fork and make a branch off of main again (there are a whole bunch of different ways to resolve the state you are in, and this is just one of them)

I'll discuss with the team switching back to 'merge commit' merge method so that this is not a problem in the future.

_Originally posted by @seanmakesgames in https://github.com/comcode-org/hackmud_wiki/issues/403#issuecomment-2027391523_

Fayti1703 commented 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.

seanmakesgames commented 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.

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.