(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
Hi,
I have a 4 cluster version 1.0.3 which was upgraded from 0.7.6 in 2 stages.
Upgrade to 1.0.0 run scrub on all nodes
Upgrade to 1.0.3
I keep getting this errors from time to time on all 4 nodes.
Is there any maintenance I can do to fix the problem?
I tried to run repair on the clu
12 matches
Mail list logo
