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. On 11/05/2011, at 11:24 AM, John Firebaugh <[email protected]> wrote: > This is what the recent commit history looks like: > > http://imgur.com/YAOq9 > > Does anyone else miss the days when all commits were rebased? I find that the > super-non-linear history makes it much more difficult to figure out what has > changed between two points, or to pinpoint the cause of a regression. > > It's too bad github's otherwise awesome pull request functionality doesn't > provide the option of rebasing rather than merging. > -- > 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. -- 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.
