On May 18, 10:29 pm, Calvin Spealman <ironfro...@gmail.com> wrote: > > 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.
I am talking about topic branches here. If you have a branch of "admin- next" for example then the workflow might need to be different. It seems the correct way to describe a Github topic branches is that they are just another way of publishing a _patch series_. In Linux this is done by sending the patches to LKML. We used to do this by Trac patches (still accepted) and now by pull requests in Github. The confusion comes from the note that "public branches should never be rebased". The topic branches should not be viewed as public branches, just as a way to publish patch series. I am not sure what to do with a pull request of a branch a site is depending upon. If the pull is not accepted into Django, how is the depended-upon branch supposed to continue and be acceptable for further pull requests into Django? If you merge and resolve conflicts (by a competing approach maybe), then you will have such a messy history it will not be pulled into Django. If you rebase, everybody depending on the branch will need to do the same. If you revert the rejected patch, then merge, you are again having a history which should not be merged into Django. Am I missing something important here? > Frankly I would prefer keeping whitespace-only commits. Better than muddling > up *real* commits with changes that had nothing to do with them. I agree, seems like there has been some confusion about this. I do think it is a good idea to have whitespace cleanup and real commits different. But having one real commit, then whitespace cleanup to _that commit_ doesn't serve any purpose except of confusing the commit history. - 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.
