Re: Django git guidelines

On 18 juil. 2012, at 11:46, Jeremy Dunck wrote: > I noticed this hasn't made it to master yet. Could it? I'm running > sprints and there's a bit of confusion on how to contribute to git. Hi Jeremy, This was committed. It's under Docs > How to get involved > Working with Git and GitHub.

Re: Django git guidelines

I noticed this hasn't made it to master yet. Could it? I'm running sprints and there's a bit of confusion on how to contribute to git. Cheers, Jeremy On Thu, Jun 7, 2012 at 9:53 AM, Aymeric Augustin wrote: > On 6 juin 2012, at 21:09, Anssi Kääriäinen

Re: Django git guidelines

On 6 juin 2012, at 21:09, Anssi Kääriäinen wrote: > I am sure there is still a lot to polish. I might have tried to change > too big portion of the docs in one go. Still, I would like to commit > what I have tomorrow, so that the sprinters at djangocon have the > possibility to use the guidelines

Re: Django git guidelines

On May 22, 11:54 pm, Alex Ogier wrote: > On Tue, May 22, 2012 at 4:34 PM, Richard Laager wrote: > > On Tue, 2012-05-22 at 04:18 -0700, Anssi Kääriäinen wrote: > >> if the patch author doesn't do the final squashing, then > >> she/he will not end up as

Re: Django git guidelines

On Tue, May 22, 2012 at 4:34 PM, Richard Laager wrote: > On Tue, 2012-05-22 at 04:18 -0700, Anssi Kääriäinen wrote: >> if the patch author doesn't do the final squashing, then >> she/he will not end up as the "Author" in the commit logs. > > This isn't an issue. Just do: >    

Re: Django git guidelines

On Tue, 2012-05-22 at 04:18 -0700, Anssi Kääriäinen wrote: > if the patch author doesn't do the final squashing, then > she/he will not end up as the "Author" in the commit logs. This isn't an issue. Just do: git commit --author "John Doe " And if the "squash merge"

Re: Django git guidelines

On May 18, 11:34 pm, Anssi Kääriäinen wrote: > > 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

Re: Django git guidelines

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

Re: Django git guidelines

On May 18, 10:29 pm, Calvin Spealman 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).

Re: Django git guidelines

On Fri, May 18, 2012 at 7:38 AM, Anssi Kääriäinen wrote: > On May 18, 1:44 pm, Calvin Spealman wrote: >> >  - When upstream has changed use git rebase instead of git pull >> >> A rebase workflow has always been problematic, in my experience. It will

Re: Django git guidelines

On May 18, 2012, at 12:19 PM, Anssi Kääriäinen wrote: > I do not want us to have single commit per pull request. Instead I > would like to see nice clean logical commits. These make bisecting as > easy as possible. So, we mostly agree here. My feeling is that we want every commit in the main tree

Re: Django git guidelines

On May 18, 8:43 pm, Donald Stufft wrote: > In my experience, squash makes git bisect harder, instead finding the bad > commit to be a small, atomic change, you're often given a large change where > you must then determine which change out of the entire commit caused the

Re: Django git guidelines

On May 18, 8:40 pm, Alex Ogier wrote: > I am +1 on merge --squash. The reason is that there is tremendous > value to having a mostly linear mainline development branch, > especially for one so widely depended on as Django's. My feeling is > that we should aim to have the

Re: Django git guidelines

On Friday, May 18, 2012 at 1:40 PM, Alex Ogier wrote: > I am +1 on merge --squash. The reason is that there is tremendous > value to having a mostly linear mainline development branch, > especially for one so widely depended on as Django's. My feeling is > that we should aim to have the official

Re: Django git guidelines

I am +1 on merge --squash. The reason is that there is tremendous value to having a mostly linear mainline development branch, especially for one so widely depended on as Django's. My feeling is that we should aim to have the official branches consist of only those commits that we would feel

Re: Django git guidelines

On Friday, May 18, 2012 at 12:30 PM, Anssi Kääriäinen wrote: > On May 18, 6:08 pm, Donald Stufft (http://gmail.com)> wrote: > > I personally prefer doing normal merges with --no-ff. While "clean up > > whitespace" > > commits are extraneous, they don't particularly

Re: Django git guidelines

On May 18, 6:08 pm, Donald Stufft wrote: > I personally prefer doing normal merges with --no-ff. While "clean up > whitespace" > commits are extraneous, they don't particularly hurt anything. If an incoming > pull > request is particularly messy it's easy enough to say

Re: Django git guidelines

On May 18, 6:04 pm, Carl Meyer wrote: > All in all, I would be -1 on making rebase a required part of > contributing to Django. I would prefer to leave this choice up to the > contributor, and say something like: > > "If you want your own name on the final commit in master, feel

Re: Django git guidelines

On Friday, May 18, 2012 at 11:04 AM, Carl Meyer wrote: > Hi Anssi, > > Thanks for working on git usage guidelines! I very much agree that a > pull request should only be created when the contributor considers the > branch finished and ready for review and merge (for instance, there > should

Re: Django git guidelines

Hi Anssi, Thanks for working on git usage guidelines! I very much agree that a pull request should only be created when the contributor considers the branch finished and ready for review and merge (for instance, there should never be a pull request created without the necessary docs and tests).

Re: Django git guidelines

On May 18, 11:43 am, Anssi Kääriäinen wrote: > A heads up: I am working on Git and Github usage guidelines. There is > a tickethttps://code.djangoproject.com/ticket/18307, and I have a > github branch with some initial >

Re: Django git guidelines

On May 18, 1:44 pm, Calvin Spealman 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

Re: Django git guidelines

On May 18, 2012 4:43 AM, "Anssi Kääriäinen" wrote: > > 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

Re: Django git guidelines

2012/5/18 Anssi Kääriäinen > 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