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
