On May 18, 1:44 pm, Calvin Spealman <ironfro...@gmail.com> wrote: > > - When upstream has changed use git rebase instead of git pull > > A rebase workflow has always been problematic, in my experience. It will > cause previously published commits to be rewritten, changing their hashes, > and invalidating other branches, forks, or installations depending on them. > > I also think rebasing can seriously devalue the history of a branch, by > eradicating the context in which changes had been made. > > Even the got developers will recommend not rebasing public commits. I think > we should follow that advice.
The idea is that when working on a topic branch, use git rebase. The published branches (django/django/master, django/django/stable/1.4.x) will never get rewritten history (except for truly exceptional situations). The viewpoint is that the github branches people are working on are considered topic branches, and thus nobody should base their work on these branches. The take above is that topic branches published on github are nothing more than a way to publish a patch set. They are _not intended for others to work upon_. The main problem I have with assuming the github branches should never be rebased is this: 1. A developer publishes some work on github 2. A reviewer spots some minor issues (typos, whitespace issues, pep-8 issues). x. 4. Committer merges the final work into master branch. Now, the issue is what should the original developer do in step x.? He could do the fixes and add a commit. However, we do not want (possibly multiple) extraneous "whitespace cleanup" commits in there. So, the branch needs to be rebased. Other option is that the committer does a squash merge of the work. The clearest example why we can't just merge the full history is that there might be commits which break Django totally and these commits must not be merged to master. >From Git user manual (http://schacon.github.com/git/user- manual.html#problems-With-rewriting-history): """ You may still choose to publish branches whose history is rewritten, and it may be useful for others to be able to fetch those branches in order to examine or test them, but they should not attempt to pull such branches into their own work. For true distributed development that supports proper merging, published branches should never be rewritten. """ So, the issue really is what is the take on those topic branches. Are they public as in other should base their work upon the branch or not. I think most of the branches are there just for easy code review, and these branches should use the rebase workflow. - 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.
