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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
That''s actually the result of using Github''s Merge button. So it would create another commit every time you click on the merge button. On 10 พ.ค. 2554, at 19:24, John Firebaugh 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 <john.firebaugh@gmail.com> 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Best resource about this subject: Pro Git. http://progit.org/book/ch3-6.html -- LAILSON BANDEIRA http://lailsonbandeira.com/ On Tue, May 10, 2011 at 10:47 PM, Richard Hulse <richard.l.hulse@gmail.com>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. > > > On 11/05/2011, at 11:24 AM, John Firebaugh <john.firebaugh@gmail.com> > wrote: > > This is what the recent commit history looks like: > > <http://imgur.com/YAOq9>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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Tue, May 10, 2011 at 6:47 PM, Richard Hulse <richard.l.hulse@gmail.com>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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
To tell you the truth, I hate the fact that Github *always* create a commit that says "merging" stuff. What I''d rather would like to have is that Github would try to fast-forward merge first, then fallback to three-way-merge if it''s failed. On 10 พ.ค. 2554, at 22:20, John Firebaugh wrote:> On Tue, May 10, 2011 at 6:47 PM, Richard Hulse <richard.l.hulse@gmail.com> 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On 11/05/2011, at 2:20 PM, John Firebaugh <john.firebaugh@gmail.com> wrote:> . 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: >Yes, that is annoying. Perhaps you should refer the issue to github. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On 11 May 2011, at 00:24, John Firebaugh 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. >I don''t know if this will help but git log --no-merges will hide the merge commits. If you want to pinpoint a regression why not use git bisect? Chris -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.