On Tue, May 10, 2011 at 6:47 PM, Richard Hulse <[email protected]>wrote:
> In this case those branches are public, so it is a Bad Thing to rebase them > on master prior to the merge because all the sha1s change. You should only > rebase private branches, merge to local master (after a pull --rebase) then > push to upstream master. (to get linear history). > > I think that makes sense. > There are two parties to a patch or a pull request: in git parlance, the author and the committer. You are talking about the author side of the process, which is often debated, but not what I meant to discuss right now. I'm talking about what the Rails core committers do with submitted patches and pull requests. Prior to the existence of the "Merge" button on github, Rails committers would routinely rebase submitted patches onto master. This leads to a nice, clean, linear history. The "Merge" button, on the other hand, does not do rebase. In fact, it forces a merge commit even if the merge otherwise would have been a fast-forward. This leads to an extremely cluttered history: http://imgur.com/YAOq9 I'm proposing we should keep doing things the previous way (i.e., not using the "Merge" button) until github offers an option to rebase when accepting a pull request. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
