On May 18, 8:40 pm, Alex Ogier <alex.og...@gmail.com> wrote: > 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.
The problem with this approach is that the committer bandwidth is really limited. It is the bottleneck currently. The more committers need to do per patch, the more visible this limit will be. I really don't see the availability of contributors as a big problem - how to get their work into Django is the problem. The amount of Trac's open tickets with patches supports this. I agree that requiring everybody to create perfect pull requests will not work. But on the other hand we really should aim for a workflow where the more active contributors are encouraged, if not required, to create patches 100% ready for commit. The idea is that if a contributor creates constantly high quality work, there really isn't much difference between the core committer and such a contributor. A committer can just pull in the contributors work with quick sanity check (or even without one if the contributor is trusted enough). Just to be clear: Many if not most patches will need to be eventually merged in by some way of squashing. Still, if we do not even try to aim for a workflow where the contributors do as much of the work as possible, then we are throwing away part of the power of Git. Documenting that "you don't need to worry about commit message guidelines, or logical commits, the committer will take care of this by squash merging your work" will ensure we will get only large monolithic commits. The committer simply can not rework a dirty history into logical commits, or at least not with the time the committers have available. There isn't a big disagreement here. It is more about the tone of the requirements of a good pull request. We should not require perfect pull request, but we should say that if you aim to contribute to Django long term, you should learn to create good quality pull requests. BTW It is perfectly possible to have good linear commit history even without doing any squash merges: git checkout master git pull upstream master # fetch and apply the commit/commits from the pull request curl https://github.com/django/django/pull/NN.patch | git am # if the work isn't ready, you can do commits, rebase -i the commits etc.. # verify the push git push --dry-run upstream master git push upstream master - 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.
