All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Mark Brown <broonie@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>
Subject: Re: [GIT PULL] regulator updates for v3.13-rc1
Date: Mon, 25 Nov 2013 13:10:01 -0800	[thread overview]
Message-ID: <CA+55aFwPcr8TYpLUg5NP9x3RGCv4+U7vz-nNH6Br5ku3MDwaDw@mail.gmail.com> (raw)
In-Reply-To: <20131125174037.GR14725@sirena.org.uk>

On Mon, Nov 25, 2013 at 9:40 AM, Mark Brown <broonie@kernel.org> wrote:
>
> Mark Brown (4):
>       Merge remote-tracking branch 'regulator/fix/arizona' into regulator-linus
>       Merge remote-tracking branch 'regulator/fix/fixed' into regulator-linus
>       Merge remote-tracking branch 'regulator/fix/gpio' into regulator-linus
>       Merge remote-tracking branch 'regulator/fix/pfuze100' into regulator-linus

Btw, I suspect you could/should have just used an "octopus merge" to
merge these kinds of small independent branches in one go. Just list
all the branches you want to merge for one single "git merge", and
you're done.

I don't necessarily recommend doing that in general, but octopus
merges are actually quite nice for this kind of situation in that it
avoids having excessive empty merge commits. Now we end up having your
four merges, and then my one merge on top: so we have five merges for
four actual fixes. Octopus merges can end up making the history more
readable by avoiding that kind of somewhat excessive merge activity
that you otherwise easily get from having lots of small topic
branches.

But it's up to you. I like seeing topic branches, and that part is
absolutely a good git habit to get into. Octopus merges then have the
upside that they then avoid having lots of pointless small merge
commits to tie them all together, but they can make it slightly more
challenging to figure out what went wrong if problems happen. So in
this case, one option might have been to merge the three independent
driver fixes with one single octopus merge, and then merge the core
fix separately as a normal merge.

Whatever. Not a big deal, I just thought I'd mention it if you perhaps
didn't realize that git happily merges multiple branches at once..

              Linus

  reply	other threads:[~2013-11-25 21:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-25 17:40 [GIT PULL] regulator updates for v3.13-rc1 Mark Brown
2013-11-25 21:10 ` Linus Torvalds [this message]
2013-11-26  0:39   ` Mark Brown
2013-11-26  2:50     ` Linus Torvalds
2014-01-21 19:16     ` Linus Torvalds
2014-01-21 20:31       ` Mark Brown
2014-01-23  8:27       ` Takashi Iwai
2014-01-24  0:04       ` H. Peter Anvin

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=CA+55aFwPcr8TYpLUg5NP9x3RGCv4+U7vz-nNH6Br5ku3MDwaDw@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.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.