On Fri, Mar 2, 2012 at 1:06 AM, Robert Bradshaw
wrote:
> Though for a single commit, a rebase is cleaner IMHO than a merge, and
> squashing commits improves the signal-to-noise ratio of the history
> (and it's nice to be able to squash away stuff like typos).
That was my original position, but I
On Tue, Feb 21, 2012 at 3:23 PM, Keshav Kini wrote:
> Jason Grout writes:
>
>> On 2/21/12 12:19 PM, Robert Bradshaw wrote:
>>> Perhaps we could require that every state
>>> of the main line be consistant, and if it's worthwhile to preserve
>>> inconsistent history we merge it as a branch rather t
On Tue, Feb 21, 2012 at 11:39 AM, Jason Grout
wrote:
>
> Interesting. Where is this assignee field? Is it the assignee field in the
> Issues? Does setting that require that the committer be the assignee?
It's in the gray bar below the title for the PR. Anyone in the team
who owns the target r
On Tue, Feb 21, 2012 at 12:32 PM, Robert Bradshaw
wrote:
>
>> No, you can keep pushing to the branch you created the PR from, and
>> new commits show up as they are made. You can even rebase and force
>> push, and the PR will get rebased too. We do the first all the time,
>> and the second also,
On Tue, Feb 21, 2012 at 11:17 AM, Fernando Perez wrote:
> On Tue, Feb 21, 2012 at 11:03 AM, Christopher Swenson
> wrote:
>> My only possible issue with the github workflow: I'm not sure how it
>> interacts with having multiple people who have control of the "master"
>> (central) repo. When a pull
On Tue, Feb 21, 2012 at 11:03 AM, Christopher Swenson
wrote:
> My only possible issue with the github workflow: I'm not sure how it
> interacts with having multiple people who have control of the "master"
> (central) repo. When a pull request comes in, can anyone who has push access
> to the repo
I agree with a lot of what was just said.
My only possible issue with the github workflow: I'm not sure how it
interacts with having multiple people who have control of the "master"
(central) repo. When a pull request comes in, can anyone who has push
access to the repo take control of that pull r
On Tue, Feb 21, 2012 at 7:38 AM, Jason Grout
wrote:
> I'll have to think more about whether I agree with the "each commit should
> stand on its own" philosophy mentioned below. It certainly makes bisection
> easier. But sometimes huge patches make me think that each *branch* should
> stand on it
On Tue, Feb 21, 2012 at 7:43 AM, Christopher Swenson
wrote:
> Well, I believe that gerrit was designed with the Google philosophy in mind,
> so I would assume that this would mean that the software must run after each
> commit that is mailed out. (This is sort of equivalent to the way patches
> w
Well, I believe that gerrit was designed with the Google philosophy in
mind, so I would assume that this would mean that the software must run
after each commit that is mailed out. (This is sort of equivalent to the
way patches work now, as they cannot be committed unless all tests pass.)
There a
Jason,
I forwarded this thread to Shawn Pearce, the primary author of gerrit, and
have included his response below.
--Christopher
-- Forwarded message --
From: Shawn Pearce
Date: Tue, Feb 21, 2012 at 15:16
Subject: Re: [sage-devel] Re: git and gerrit
To: Christopher Swenson
Cc
Reviewed changes should be very small so that they are easy to verify and
review. Also, most changes are bugfixes or minor feature adds, so it should
not create large, hard to merge commits.
If you have such a large change, you should probably be splitting into
multiple reviews anyway.
I know the
12 matches
Mail list logo
