On Mon, Jan 9, 2012 at 9:41 AM, Sylvain Lebresne wrote:
>> The other side of the equation is that there is tremendous power to be had
>> from distributed versioning, and this proposed workflow discourages taking
>> advantage of that
>
> Would you mind elaborating, maybe be a little more concrete o
On Mon, Jan 9, 2012 at 10:02 AM, Peter Schuller wrote:
> [speaking obviously as non-committer, just offering a perspective]
>
> A potential factor to consider: If one knows that all work in topic
> branches end up merged without anyone first rebasing to clean up, you
> now have a constant trade-o
[speaking obviously as non-committer, just offering a perspective]
A potential factor to consider: If one knows that all work in topic
branches end up merged without anyone first rebasing to clean up, you
now have a constant trade-off between history readability and
committing often. I personally
Ok, I'll need to stop using Gmail. In the meantime, sorry for the
inconvenience, retrying, hoping that Gmail won't randomly screw
up the formatting this time.
So, I do don't like history that look like the following:
> commit : last nits from reviewer
> commit : oops, typo that prevented
So, I do don't like history that look like the following:
> commit : last nits from reviewer> commit : oops, typo that prevented
> compilation> commit : some more fix found during review> commit :
> refactor half of preceding patch following reviewer comments> commit : Do
> s
On Sat, Jan 7, 2012 at 2:35 AM, Radim Kolar wrote:
> Dne 5.1.2012 7:22, Peter Schuller napsal(a):
>
>> (And btw, major +1 on the transition to git!)
>
> please fix github mirror already.
https://issues.apache.org/jira/browse/INFRA-4254
--
Eric Evans
Acunu | http://www.acunu.com | @acunu
Dne 5.1.2012 7:22, Peter Schuller napsal(a):
(And btw, major +1 on the transition to git!)
please fix github mirror already.
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
(And btw, major +1 on the transition to git!)
--
/ Peter Schuller (@scode, http://worldmodscode.wordpress.com)
> So, can I summarize our policy as "git pull --rebase"?
If you're talking about the simple case of hacking away at a branch
that multiple people are working on, without "semantically" desiring,
a branch, than IMO *always* use to --rebase. Here's my stackoverflow
rant about why:
http://stacko
On Wed, Jan 4, 2012 at 6:24 PM, Eric Evans wrote:
> Does this mean we're following the workflow advocated at
> http://darwinweb.net/articles/the-case-for-git-rebase? We're rebasing
> everything that goes onto master to create a perfectly flat history?
New features, but not merges from earlier br
On Wed, Jan 4, 2012 at 3:19 PM, Jonathan Ellis wrote:
> On Wed, Jan 4, 2012 at 11:48 AM, paul cannon wrote:
>> On Wed, Jan 4, 2012 at 11:40 AM, Jonathan Ellis wrote:
>>
>>> So, can I summarize our policy as "git pull --rebase"?
>>>
>>
>> I'd rather have the normal case be to use topic branches f
On Wed, Jan 4, 2012 at 3:19 PM, Jonathan Ellis wrote:
> On Wed, Jan 4, 2012 at 11:48 AM, paul cannon wrote:
> > On Wed, Jan 4, 2012 at 11:40 AM, Jonathan Ellis
> wrote:
> >
> >> So, can I summarize our policy as "git pull --rebase"?
> >>
> >
> > I'd rather have the normal case be to use topic b
On Wed, Jan 4, 2012 at 11:48 AM, paul cannon wrote:
> On Wed, Jan 4, 2012 at 11:40 AM, Jonathan Ellis wrote:
>
>> So, can I summarize our policy as "git pull --rebase"?
>>
>
> I'd rather have the normal case be to use topic branches for work, so
> --rebase doesn't come in to the picture, but yeah
On Wed, Jan 4, 2012 at 11:40 AM, Jonathan Ellis wrote:
> So, can I summarize our policy as "git pull --rebase"?
>
I'd rather have the normal case be to use topic branches for work, so
--rebase doesn't come in to the picture, but yeah, pull --rebase is a
better default.
A more important bit of p
On Wed, Jan 4, 2012 at 11:30 AM, paul cannon wrote:
> On Wed, Jan 4, 2012 at 10:57 AM, Eric Evans wrote:
>> Personally, I do prefer to rebase my branches while they are private,
>> but that's for purposes of easing review; I've never felt I needed a
>> flatter history to make life easier (with Gi
On Wed, Jan 4, 2012 at 10:57 AM, Eric Evans wrote:
> On Wed, Jan 4, 2012 at 9:59 AM, Jonathan Ellis wrote:
> > On Tue, Jan 3, 2012 at 1:21 PM, paul cannon wrote:
> >> Surely we'd want to follow normal git practices here: rebasing is almost
> >> never appropriate once a branch is pushed to a pub
On Wed, Jan 4, 2012 at 9:59 AM, Jonathan Ellis wrote:
> On Tue, Jan 3, 2012 at 1:21 PM, paul cannon wrote:
>> Surely we'd want to follow normal git practices here: rebasing is almost
>> never appropriate once a branch is pushed to a public repo, where other
>> people might have gotten it.
>>
>> W
On Tue, Jan 3, 2012 at 1:21 PM, paul cannon wrote:
> Surely we'd want to follow normal git practices here: rebasing is almost
> never appropriate once a branch is pushed to a public repo, where other
> people might have gotten it.
>
> Where you might rebase a plain patch series on top of new devel
On Tue, Jan 3, 2012 at 1:21 PM, paul cannon wrote:
> On Wed, Dec 28, 2011 at 1:55 PM, Eric Evans wrote:
>
>> There are also some matters of work-flow or process that we need to
>> hashed out. For example, how do we handle reviews now? Do we
>> continue to mandate/recommend/allow rebasing?
>>
>
On Wed, Dec 28, 2011 at 1:55 PM, Eric Evans wrote:
> There are also some matters of work-flow or process that we need to
> hashed out. For example, how do we handle reviews now? Do we
> continue to mandate/recommend/allow rebasing?
>
Surely we'd want to follow normal git practices here: rebasi
On Thu, Dec 29, 2011 at 2:30 PM, Eric Evans wrote:
> On Thu, Dec 29, 2011 at 9:18 AM, Eric Evans wrote:
>> On Thu, Dec 29, 2011 at 12:08 AM, Dave Brosius wrote:
>>> doing
>>>
>>> git clone http://git-wip-us.apache.org/repos/asf/cassandra.git cassandra
>>>
>>> proceeded as a normal clone until th
On Thu, Dec 29, 2011 at 11:56 AM, Radim Kolar wrote:
> git://git.apache.org/cassandra.git
>
> this still works?
I'm not sure what the status of this is, or what the future holds for
it. I would stick with http://git-wip.us.apache.org to be on the
safe-side.
--
Eric Evans
Acunu | http://www.acu
On Thu, Dec 29, 2011 at 9:18 AM, Eric Evans wrote:
> On Thu, Dec 29, 2011 at 12:08 AM, Dave Brosius wrote:
>> doing
>>
>> git clone http://git-wip-us.apache.org/repos/asf/cassandra.git cassandra
>>
>> proceeded as a normal clone until the end when i received
>>
>> warning: remote HEAD refers to n
git://git.apache.org/cassandra.git
this still works?
On Thu, Dec 29, 2011 at 12:08 AM, Dave Brosius wrote:
> On 12/28/2011 02:55 PM, Eric Evans wrote:
>>
>> While this is something we had talked about for ages, the actual
>> switch-over happened rather abruptly, and Cassandra's canonical
>> repository is now hosted in Git.
>>
>> For instructions on
On 12/28/2011 02:55 PM, Eric Evans wrote:
While this is something we had talked about for ages, the actual
switch-over happened rather abruptly, and Cassandra's canonical
repository is now hosted in Git.
For instructions on getting started, see
https://git-wip-us.apache.org. We've also started
On Wed, Dec 28, 2011 at 9:32 PM, Dave Brosius wrote:
> On 12/28/2011 08:54 PM, Eric Evans wrote:
>>
>> On Wed, Dec 28, 2011 at 6:25 PM, Stephen Connolly
>> wrote:
>>>
>>> just the question, where do us contributors who are not committers but
>>> have
>>> cla's on file (ie already asf committers)
On 12/28/2011 08:54 PM, Eric Evans wrote:
On Wed, Dec 28, 2011 at 6:25 PM, Stephen Connolly
wrote:
just the question, where do us contributors who are not committers but have
cla's on file (ie already asf committers) push our changes?
To the best of my knowledge, that distinction doesn't matt
On Wed, Dec 28, 2011 at 6:25 PM, Stephen Connolly
wrote:
> just the question, where do us contributors who are not committers but have
> cla's on file (ie already asf committers) push our changes?
To the best of my knowledge, that distinction doesn't matter. It's up
to the committer to make sure
Hi Stephen,
See
http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/201112.mbox/%3ca603ffce-623b-43e9-87f8-39baa51c7...@gbiv.com%3E
On Wed, Dec 28, 2011 at 7:25 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> just the question, where do us contributors who are not co
just the question, where do us contributors who are not committers but have
cla's on file (ie already asf committers) push our changes?
hoping this change will make contributing easier.
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsens
While this is something we had talked about for ages, the actual
switch-over happened rather abruptly, and Cassandra's canonical
repository is now hosted in Git.
For instructions on getting started, see
https://git-wip-us.apache.org. We've also started putting random
administrivia in the wiki at
42 matches
Mail list logo
