linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Pitre <nico@fluxnic.net>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Arnd Bergmann <arnd@arndb.de>, Junio C Hamano <gitster@pobox.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	linux-kernel@vger.kernel.org, Olof Johansson <olof@lixom.net>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [GIT PULL 05/11] SoC-level changes for tegra and omap
Date: Wed, 11 Jan 2012 16:53:15 -0500 (EST)	[thread overview]
Message-ID: <alpine.LFD.2.02.1201111648240.2722@xanadu.home> (raw)
In-Reply-To: <CAMuHMdVvQzdxw0B3ZMtJej=9Qwm7Qbd5aenSOfa=QPhX8UUt2w@mail.gmail.com>

On Wed, 11 Jan 2012, Geert Uytterhoeven wrote:

> On Wed, Jan 11, 2012 at 19:12, Arnd Bergmann <arnd@arndb.de> wrote:
> 
> [...]
> 
> > Now let's assume that all dependencies are merged upstream already
> > and I just want to send out three pull requests. The first
> > pull request generally works fine, though it could be that some
> > version of git in the past would include the diff between v3.3-rc2
> > and v3.3-rc4 in the diffstat. For the second pull request, I merge
> > v3.3 with A and send do 'git request-pull B origin
> > tmp-merge-of-upstream-and-A'. This seems to generate the correct
> > list of patches, but the wrong diffstat (diffstat also contains
> > the diff between v3.3-rc4 and v3.3-rc5, although that is indeed
> > part of tmp-merge-of-upstream-and-A. For submitting branch C,
> > I have to merge upstream, A, B and the dependencies together
> > and then send a pull request against that. This typically also
> > includes the external dependencies in the diffstat.
> 
> <throwing the bat in the hen house, no idea if this expression exists
> in other languages than Dutch>
> And all of this would look nice if you would have done a rebase on top of the
> latest tagged version of Linus' tree that contains all prerequisites, right?
> </throwing...>

No, because as a maintainer merging other people's branches, you're not 
supposed to rebase anything.  Linus did flame maintainers doing that in 
the past.  The reason is that by rebasing you modify the environment in 
which the changes are applied which voids the testing that the original 
author did.


Nicolas

  reply	other threads:[~2012-01-11 21:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-09 22:12 [GIT PULL 00/11] arm-soc changes Arnd Bergmann
2012-01-09 22:12 ` [GIT PULL 01/11] Non-critical bug fixes Arnd Bergmann
2012-01-09 22:12 ` [GIT PULL 02/11] Cleanups on various subarchitectures Arnd Bergmann
2012-01-09 22:12 ` [GIT PULL 03/11] Device tree conversions for samsung and tegra Arnd Bergmann
2012-01-09 22:12 ` [GIT PULL 04/11] Cleanups for the Samsung platforms Arnd Bergmann
2012-01-09 22:12 ` [GIT PULL 05/11] SoC-level changes for tegra and omap Arnd Bergmann
2012-01-09 22:37   ` Linus Torvalds
2012-01-10  8:39     ` Russell King - ARM Linux
2012-01-10 16:08       ` Linus Torvalds
2012-01-11  0:15         ` Junio C Hamano
2012-01-11 18:12           ` Arnd Bergmann
2012-01-11 20:29             ` Geert Uytterhoeven
2012-01-11 21:53               ` Nicolas Pitre [this message]
2012-01-11 23:21               ` Linus Torvalds
2012-01-12  6:32                 ` Geert Uytterhoeven
2012-01-12  6:41                   ` Linus Torvalds
2012-01-09 22:12 ` [GIT PULL 06/11] Board-level changes Arnd Bergmann
2012-01-09 22:12 ` [GIT PULL 07/11] New feature development Arnd Bergmann
2012-01-09 22:12 ` [GIT PULL 08/11] Driver specific changes Arnd Bergmann
2012-01-09 22:12 ` [GIT PULL 09/11] power management changes for omap and imx Arnd Bergmann
2012-01-09 22:12 ` [GIT PULL 10/11] timer changes for msm Arnd Bergmann
2012-01-09 22:12 ` [GIT PULL 11/11] clock management changes for i.MX Arnd Bergmann
2012-01-09 22:55 ` [GIT PULL 00/11] arm-soc changes Linus Torvalds

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=alpine.LFD.2.02.1201111648240.2722@xanadu.home \
    --to=nico@fluxnic.net \
    --cc=arnd@arndb.de \
    --cc=geert@linux-m68k.org \
    --cc=gitster@pobox.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=olof@lixom.net \
    --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 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).