On Sep 10, 2014, at 4:21 PM, Malte <
malteb...@gmail.com> wrote:
> That's a lot of locales to change though. I am still somewhat new to Git. How would you go about it?
I asked about Git recently on the Django Core Mentorship list. Carl Meyer responded with a really good workflow for creating a PR. I have copied key parts of his response below.
Begin forwarded message:
> The best way [...] is to always use a new branch for
> each pull request, instead of making your changes directly in master.
> This way it doesn't matter whether your PR is merged exactly as-is, or
> is squashed or otherwise modified (as happened in this case) -- either
> way master always tracks exactly what happened upstream, without
> interference from your original version of the changes.
>
> Sample sequence of git commands you might use to make a new local branch
> and make a PR from it (with interspersed commentary):
>
> # First make sure your new branch will based on the latest master
> $ git checkout master
> # If your local master tracks upstream, you can omit "upstream master":
> $ git pull upstream master
>
> # Create a branch: I often name it tXXXXX for the Trac ticket #
> $ git checkout -b t22951
>
> # Make your changes and commit them...
>
> # Then push your local branch to a branch of the same name
> # on your GitHub remote. The -u sets up a "tracking" relationship,
> # so in future you can just "git push" from this branch and it will
> # automatically know where to push to.
> $ git push -u origin t22951
>
> Now if you visit GitHub shortly after this push, it'll automatically
> prompt you to create a pull-request from your recently-pushed t22951 branch.
Tim Graham also pointed me to a part of the documentation that may be helpful:
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist
Hope that helps,
Andrew