All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jens Axboe <axboe@fb.com>, Jan Kara <jack@suse.cz>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linuxpatches@star.c10r.facebook.com
Subject: Re: [GIT PULL] Core block IO bits for 3.15-rc
Date: Wed, 2 Apr 2014 19:01:11 +0200	[thread overview]
Message-ID: <20140402170108.GD16397@localhost.localdomain> (raw)
In-Reply-To: <CA+55aFxcy=TDWucdnjHPPp=Dh-boA0uPLkKQP3oCGaKMDg-h_A@mail.gmail.com>

On Wed, Apr 02, 2014 at 08:02:13AM -0700, Linus Torvalds wrote:
> On Wed, Apr 2, 2014 at 7:00 AM, Frederic Weisbecker <fweisbec@gmail.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

Yeah indeed. I think maybe I started to work on top of a stale tree and got
confused with conflicts against pre v3.13 commits that were actually merged
upstream for a while already.

But you're right, looking at it closer, the real conflicts against pending -block
patches weren't that bad actually

Anyway, thanks for pulling it in the end, I'll be more careful!

      reply	other threads:[~2014-04-02 17:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-01 19:05 [GIT PULL] Core block IO bits for 3.15-rc Jens Axboe
2014-04-02  2:43 ` Linus Torvalds
2014-04-02  2:48   ` Jens Axboe
2014-04-02 14:09     ` Frederic Weisbecker
2014-04-02 14:00   ` Frederic Weisbecker
2014-04-02 15:02     ` Linus Torvalds
2014-04-02 17:01       ` Frederic Weisbecker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140402170108.GD16397@localhost.localdomain \
    --to=fweisbec@gmail.com \
    --cc=axboe@fb.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxpatches@star.c10r.facebook.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.