Hi all, New to this list but I saw this post and thought I would chime in with my two cents. I'm not really a Django contributor (yet) but I have a fair bit of experience using Git and Django both personally and professionally.
I can understand the hesitation for using rebase on public commits. I think rebasing after a pull request has already been issued might not be the best idea. However, I think contributors should generally be encouraged to rebase rather than pull. The reason being is that if a topic branch is closely tracking it's parent (which I assume would be a common situation) you end up with a lot of merge commits which make the history hard to follow. If a change in a commit requires adapting due to upstream changes, I personally think it's preferable for the contributor to do the work of hiding this fact via rebase. It helps group logical changes together and simply makes the history much easier to read. For development branches, I don't see the fact that history is changing to be a problem. (If someone is basing work off a development branch, should they not expect things to break?) Anyway, really happy to see Django move to GitHub and looking forward to tossing some code your way in the future. :) Cheers, -- Michael Le vendredi 18 mai 2012 04:43:13 UTC-4, Anssi Kääriäinen a écrit : > > A heads up: I am working on Git and Github usage guidelines. There is > a ticket https://code.djangoproject.com/ticket/18307, and I have a > github branch with some initial work > https://github.com/akaariai/django/tree/django_git_guidelines > (or for changeset > https://github.com/akaariai/django/compare/django_git_guidelines) > > The guidelines in short: > - For trivial patches use pull requests directly > - For non-trivial patches, create a trac ticket, announce your work > by linking to your github branch, and when your work is ready to be > pulled in, only then do a pull request > - Aim for logically contained commits, commit messages of 50 char > summary line, 72 char paragraphs thereafter. > - When upstream has changed use git rebase instead of git pull > - When you do additional fixes to your work, use git rebase -i so > that your work still fullfills the logical commits requirement. > > Lots of more details in the WIP branch. All feedback welcomed. Lets > keep the discussion of any high-level issues here on django- > developers, as the choices made impact the whole community. > > The biggest issue is how we aim to use the pull requests. My take on > this is that pull requests should be only used for work ready for > committer. That is, the original author feels the work is ready, or he > doesn't know how to do anything more. If the pull requests are used > for feature requests or work-in-progress patches we risk having lots > of open tickets and lots of open pull requests. > > I have tried to gather pieces of wisdom around the net. I am not too > experienced with Git, so if you have experience with the above > mentioned and/or other Git workflows feedback is appreciated. > > - Anssi Le vendredi 18 mai 2012 04:43:13 UTC-4, Anssi Kääriäinen a écrit : > > A heads up: I am working on Git and Github usage guidelines. There is > a ticket https://code.djangoproject.com/ticket/18307, and I have a > github branch with some initial work > https://github.com/akaariai/django/tree/django_git_guidelines > (or for changeset > https://github.com/akaariai/django/compare/django_git_guidelines) > > The guidelines in short: > - For trivial patches use pull requests directly > - For non-trivial patches, create a trac ticket, announce your work > by linking to your github branch, and when your work is ready to be > pulled in, only then do a pull request > - Aim for logically contained commits, commit messages of 50 char > summary line, 72 char paragraphs thereafter. > - When upstream has changed use git rebase instead of git pull > - When you do additional fixes to your work, use git rebase -i so > that your work still fullfills the logical commits requirement. > > Lots of more details in the WIP branch. All feedback welcomed. Lets > keep the discussion of any high-level issues here on django- > developers, as the choices made impact the whole community. > > The biggest issue is how we aim to use the pull requests. My take on > this is that pull requests should be only used for work ready for > committer. That is, the original author feels the work is ready, or he > doesn't know how to do anything more. If the pull requests are used > for feature requests or work-in-progress patches we risk having lots > of open tickets and lots of open pull requests. > > I have tried to gather pieces of wisdom around the net. I am not too > experienced with Git, so if you have experience with the above > mentioned and/or other Git workflows feedback is appreciated. > > - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/wuFOPdkBjX0J. 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.
