lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 25 Nov 2013 13:10:01 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [GIT PULL] regulator updates for v3.13-rc1

On Mon, Nov 25, 2013 at 9:40 AM, Mark Brown <broonie@...nel.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ