LKML Archive on
help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Andreas Gruenbacher <>
Cc: cluster-devel <>,
	LKML <>
Subject: Re: GFS2: Pull Request
Date: Wed, 8 May 2019 11:06:37 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, May 8, 2019 at 10:55 AM Linus Torvalds
<> wrote:
> See what I'm saying? You would ask me to pull the un-merged state, but
> then say "I noticed a few merge conflicts when I did my test merge,
> and this is what I did" kind of aside.

Side note: this is more important if you know of a merge issue that
doesn't cause a conflict, and that I won't see in my simple build

For example, in this case, the merge issue doesn't cause a conflict
(because it's a totally new user of bio_for_each_segment_all() and the
syntax changed in another branch), but I see it trivially when I do a
test build, since the compiler spews out lots of warnings, and so I
can trivially fix it up (and you _mentioning_ the issue gives me the
heads up that you knew about it and what it's all about).

But if it's other architectures, or only happens under special config
options etc, I might not have seen the merge issue at all. And then
it's really good if the maintainer talks about it and shows that yes,
the maintainer knows what he's doing.

Now I'm in the situation where I have actually done the merge the way
I *like* doing them, and without your superfluous merge commit. But if
I use my merge, I'll lose the signature from your tag, because you
signed *your* merge that I didn't actually want to use at all.

See? Your "helpful" merge actually caused me extra work, and made me
have to pick one of two *worse* situations than if you had just tagged
your own development tree. Either my tree has a extra pointless merge
commit, or my tree lacks your signature on your work.

I'll just undo my pull, and delay it all in the hope that you'll just
send me a new signed tag of the non-merged state.


  reply	other threads:[~2019-05-08 18:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-08 11:48 Andreas Gruenbacher
2019-05-08 17:55 ` Linus Torvalds
2019-05-08 18:06   ` Linus Torvalds [this message]
2019-05-08 20:17     ` Andreas Gruenbacher
2019-05-08 20:21       ` Linus Torvalds
2019-05-08 20:58       ` Jonathan Corbet
2019-05-08 21:05         ` Linus Torvalds
2019-05-08 21:50           ` Jonathan Corbet
2019-05-28 18:55   ` cross-merges with MFD tree (was: Re: GFS2: Pull Request) Jacek Anaszewski
2019-05-29 11:40     ` Lee Jones
  -- strict thread matches above, loose matches on Subject: below --
2010-05-18  8:38 GFS2: Pull request Steven Whitehouse
2010-03-02 11:03 Steven Whitehouse
2009-12-03 15:01 Steven Whitehouse
2009-09-14  8:08 Steven Whitehouse
2009-06-11 10:51 Steven Whitehouse
2009-04-15 11:26 Steven Whitehouse
2009-03-24 12:20 Steven Whitehouse
2009-01-05  9:34 Steven Whitehouse
2008-01-25  9:46 GFS2 " Steven Whitehouse

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 \
    --in-reply-to='' \ \ \ \ \
    --subject='Re: GFS2: Pull Request' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).