On Fri, May 18, 2012 at 7:38 AM, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > 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.
You are making a lot of assumptions about the branches someone might send via pull request. It is entirely valid, and often _preferable_ that someone is depending on these. Maybe they were running their site on this branch, developing the feature to support something they needed, or simply as a way to test it in the wild. Maybe someone else based their own work on an existing topic branch. Also, we can't assume that merging back to upstream is the only reason someone may have created this branch. > 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. Frankly I would prefer keeping whitespace-only commits. Better than muddling up *real* commits with changes that had nothing to do with them. > 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. > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy -- 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.