On Thu, Jan 5, 2012 at 10:58 AM, Sylvain Lebresne wrote:
>> This discourages collaboration because anyone that might fork
>> github.com/author/666 is sitting on a powder keg.
>
> Alright, but then what is it you're proposing?
That we use rebase on private topic branches as a courtesy to
reviewers
On Thu, Jan 5, 2012 at 4:50 AM, Sylvain Lebresne wrote:
> Also, if committer !=
> reviewer, there is the slight issue of how the committer make sure
> that he commits what has been reviewer (i.e, that author hasn't made
> some last minute, post-review change). But I suppose we can either say
> "do
On Thu, Jan 5, 2012 at 10:58 AM, Sylvain Lebresne wrote:
> Again, I was more talking about the only reasonable solution I saw.
> Because to be clear, if the history for some issue 666 in say trunk looks
> like:
>
> commit : last nits from reviewer
> commit : oops, typo that prevented commi
On 1/5/12 9:06 AM, Jonathan Ellis wrote:
On Thu, Jan 5, 2012 at 10:58 AM, Sylvain Lebresne wrote:
Again, I was more talking about the only reasonable solution I saw.
Because to be clear, if the history for some issue 666 in say trunk looks like:
commit : last nits from reviewer
commit
I'm by no means a git guru, but just happened to attend a meeting last
night where the presenter addressed this exact issue. He has a pretty
slick process that kept the master/trunk clean without rebasing by
squashing a set of commits into a single commit when merged to trunk.
(using git squash?)
On Thu, Jan 5, 2012 at 10:58 AM, Sylvain Lebresne wrote:
> Again, I was more talking about the only reasonable solution I saw.
> Because to be clear, if the history for some issue 666 in say trunk looks
> like:
>
> commit : last nits from reviewer
> commit : oops, typo that prevented comm
> This discourages collaboration because anyone that might fork
> github.com/author/666 is sitting on a powder keg.
Alright, but then what is it you're proposing?
> At best it's yak shaving. At worst it's going to result in some very
> frustrated contributors. This is one of the major reasons w
On Thu, Jan 5, 2012 at 4:50 AM, Sylvain Lebresne wrote:
> I agree that having merge commits each time a new "patch" is committed
> is a pain and adds no useful information imo (to be clear I'm not
> talking of actual merge (like say cassandra-1.0 -> trunk)), so +1 on
> using git pull --rebase to a
Seriously Gmail ?! F@&* you!
Trying this again, hopefully it'll get it right this time:
I agree that having merge commits each time a new "patch" is committed
is a pain and adds no useful information imo (to be clear I'm not
talking of actual merge (like say cassandra-1.0 -> trunk)), so +1 on
usi
I agree that having merge commits in the history each time a new "patch"
is committed is a pain and adds no useful information imo (to be clear I'm
not talking of actual merge (like say cassandra-1.0 -> trunk)), so +1 on
using git pull --rebase to avoid it (I'm the first one to not have used it but
10 matches
Mail list logo
