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.
https
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 wrote:
>> I am sure there is still a lot
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 a
I have update the working with git guidelines based on the above
discussions. Here is the stats of the whole of the work:
docs/internals/contributing/committing-code.txt| 108 -
.../contributing/writing-code/branch-policy.txt| 171
-
docs/internals/contributing/writin
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 the "Author" in the commit logs.
>
> > This i
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:
> git commit --author "
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" workflow (which isn't som
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 on this branch,
> > develo
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.
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). The viewpoint is that t
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
>> cause previously published commits to be rew
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
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
> issue.
I do not want us
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 official branches consist
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 br
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 comfor
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 hurt anything. If an
> > incom
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 that the pull request is
>
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 free to
> rebase y
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 never
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). Ha
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
> workhttps://github.com/akaariai/django/tree/django_git_guidelines
> (or for
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 invalidating other branches
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
https://github.com/akaariai/django/tree/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
> (or for changeset
> http
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/
26 matches
Mail list logo