[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxcy=TDWucdnjHPPp=Dh-boA0uPLkKQP3oCGaKMDg-h_A@mail.gmail.com>
Date: Wed, 2 Apr 2014 08:02:13 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: Jens Axboe <axboe@...com>, Jan Kara <jack@...e.cz>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linuxpatches@...ups.facebook.com
Subject: Re: [GIT PULL] Core block IO bits for 3.15-rc
On Wed, Apr 2, 2014 at 7:00 AM, Frederic Weisbecker <fweisbec@...il.com> wrote:
>
> So yeah that's because I was worried about strong conflicts. What kind of approach
> do you prefer then to solve that kind of issue? Do you prefer that we create a seperate
> branch and deal with non trivial nor small conflicts on merge window time?
I'd indeed rather see a separate branch, and deal with the conflicts.
And in fact I think you over-estimate the conflicts. The smp function
naming changes were trivial as far as outside users were concerned,
and while the "stop abusing fileds in csd" might have clashed more
with the rest of the block changes (because they were actually to the
block functions), I doubt it would have been painful. In fact, looking
at "fifo_time" there should be no conflicts at all, and the queuelist
changes look like they would have had a *trivial* conflict with
"blk-mq: merge blk_mq_insert_request and blk_mq_run_request" just
because there were changes nearby. Even that is debatable - it's
possible git would just have resolved that one automatically too.
So I think that the patches from you and Honza could easily have been
in another branch, and had trivial or no conflicts with the other
block changes.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists