archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Matthew Wilcox <>
Cc: linux-mm <>,
	linux-fsdevel <>,
	Linux Kernel Mailing List <>
Subject: Re: [GIT PULL] XArray for 4.19
Date: Tue, 21 Aug 2018 20:00:18 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Aug 21, 2018 at 7:50 PM Matthew Wilcox <> wrote:
> So, should I have based just on your tree and sent you a description of
> what a resolved conflict should look like?


Or preferably not rebasing at all, just starting from a good solid
base for new development in the first place.

Sometimes you start from the wrong point, and decide that you really
need to rebase, but then you should rebase to a more stable point, not
on top of some random independent development.

Rebasing can be a really good tool to clean up development that was
haphazard - maybe as you  go along you notice that something you did
earlier turned out to be counter-productive, so you rebase and clean
up your history that has not been made public yet.

But when you send me a big new feature, the absolutely *last* thing I
want to ever see is to see it based on some random unstable base.

And rebasing to avoid merge conflicts is *always* the wrong thing to
do, unless the reason you're rebasing is "hey, I wrote this feature
ages ago, I need to really refresh it to a more modern and stable
kernel, so I'll rebase it onto the current last release instead, so
that I have a good starting point".

And even then the basic reason is not so much that there were
conflicts, but that you just want your series to make more sense on
its own, and not have one horribly complex merge that is just due to
the fact that it was based on something ancient.

The absolute last thing I want to see during the merge window is
multiple independent features that have been tied together just
because they are rebased on top of each other.

Because that means - as in this case - that if one branch has
problems, it now affects all of them.

Merge conflicts aren't bad. In 99% of all cases, the conflict is
trivial to solve. And the cost of trying to deal with them with
rebasing is much much higher.


  reply	other threads:[~2018-08-22  3:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-13 16:13 [GIT PULL] XArray for 4.19 Matthew Wilcox
2018-08-22  2:09 ` Linus Torvalds
2018-08-22  2:50   ` Matthew Wilcox
2018-08-22  3:00     ` Linus Torvalds [this message]
2018-08-22 18:23       ` Matthew Wilcox
2018-08-22 18:41         ` Linus Torvalds
2018-08-24  5:25   ` Stephen Rothwell
2018-08-22 17:40 ` Christopher Lameter
2018-08-22 17:43   ` Linus Torvalds
2018-08-22 18:23     ` Dan Williams
2018-08-24 13:21   ` Vlastimil Babka
2018-08-24 14:12     ` Christopher Lameter

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:

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

  git send-email \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).