[ruby-core:94227] [Ruby master Misc#16093] Prohibit a "foxtrot merge" instead of a merge commit
From:
takashikkbn@...
Date:
2019-08-09 16:33:16 UTC
List:
ruby-core #94227
Issue #16093 has been updated by k0kubun (Takashi Kokubun). Apologies, according to the chat history, it turned out that @mame was not the only person opposed to merge commits. I'll update the description to reflect the facts later. > keep a true linear history, as I find it makes reviewing the history simpler. Yeah, I understand it's a trade-off. In general, it could cause a mess of commit logs. Though, while I'm not sure how you define a "true" linear history, my point is that in this particular case we'll be able to see a linear history which will never be reversed by having the step 2 of "Solution" if we use `git log --no-merges`, just like we did not have any merge commits. ---------------------------------------- Misc #16093: Prohibit a "foxtrot merge" instead of a merge commit https://bugs.ruby-lang.org/issues/16093#change-80528 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal * Assignee: ---------------------------------------- ## Background * When we migrated the canonical Ruby repository from Subversion to Git [Misc #14632], in that ticket nobody had objected to allowing a merge commit in the repository. * However, @mame has [prohibited](https://github.com/ruby/ruby-commit-hook/commit/d7759cca6282741ecc9c46053166a1f5f5779c10#diff-7e61afe505452158c45dfa32ea7d7a14) to push a merge commit to the master branch. * His motivation was to make it possible to efficiently list up revisions to be built by his [rubyfarmer](https://github.com/mame/rubyfarmer) without having a data store. * If we do not make a merge commit, there's only one way to make a pull request "Merged" on GitHub ruby/ruby: * Push commits in the pull requests to the master branch when their parent revision is the same as the master branch's one. * Therefore, we have not been able to make a pull request "Merged" when a pull request's branch needs to be rebased before pushing it to the master branch. * But force-pushing the rebased commits to their author's branch is a bad habit and we do not want to do so. ## Problem * Some contributors get confused when their pull request is committed to the master branch but it's marked as "Closed" on GitHub [Misc #16089]. * Even though we clarified the situation in https://bugs.ruby-lang.org/projects/ruby/wiki/HowToContribute, a first-time contributor could be confused and the person might complain about it to the committer. ## Solution 1. Improve the rubyfarmer's implementation to make it work even if we had merge commits. https://github.com/mame/rubyfarmer/pull/1 2. To maintain a consistent linear history in the git log even after allowing merge commits, implement a guard to prevent a ["foxtrot merge"](https://blog.developer.atlassian.com/stop-foxtrots-now/) in the pre-receive hook. * Details: https://devblog.nestoria.com/post/98892582763/maintaining-a-consistent-linear-history-for-git 3. Allow pushing merge commits to the master branch. I'll implement the 2 and 3 soon, assuming that @mame had been the only person who had an objection to merge commits. Please let me know if you have any opinion about this. -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>