I am +1 on merge --squash. The reason is that there is tremendous value to having a mostly linear mainline development branch, especially for one so widely depended on as Django's. My feeling is that we should aim to have the official branches consist of only those commits that we would feel comfortable checking out and developing with. It is much nicer to run "git log" and see a series of focused bug fix patches than it is to see a tangle of "Fix the reticulating splines by frobbing the axis" "Oops, the axis was already fixed, revert that commit" "Do the real work in hobnob.py".
In addition to making automated git bisects possible, it also lowers the bar for contributions: so long as the code changes in a pull request are sound, we can accept fragmented histories and badly formatted commit messages and put the onus on the committers to clean up commit messages for posterity. Best, Alex Ogier On Fri, May 18, 2012 at 12:48 PM, Donald Stufft <donald.stu...@gmail.com> wrote: > On Friday, May 18, 2012 at 12:30 PM, Anssi Kääriäinen wrote: > > On May 18, 6:08 pm, Donald Stufft <donald.stu...@gmail.com> wrote: > > I personally prefer doing normal merges with --no-ff. While "clean up > whitespace" > commits are extraneous, they don't particularly hurt anything. If an > incoming pull > request is particularly messy it's easy enough to say that the pull request > is > sound in theory/implementation but that they need to rebase it to clean up > the history. > > > While the white space commits aren't that serious, there are a couple > of issues which need rebasing: > - If we aim to have well formatted commit messages, any bad commit > messages must be rewritten by changing history. Git ensures there > isn't any other way. > - I believe merging in broken states (code doesn't compile etc) will > make bisecting much harder. I am not sure of this... > - I don't find it particularly good idea to have 10 lines patches > come in in 5 commits when just a single one is required. If you looks > at the pull requests, you will see this is not far fetched. > > I think here is where it's going to come down to judgement calls. If their > is an > undue amount of extraneous commits for small patches then sure either > rebasing > or squashing probably makes sense. (Or rejecting telling the author to clean > up their history). > > Commits broken for reasons other then what you are bisecting for make bisect > a tad bit harder > but not terribly so, basically you'd just take a peek at the log and switch > to a nearby commit and > test that one instead. > > > > - Anssi > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
