* [GIT PULL] regulator updates for v3.13-rc1
@ 2013-11-25 17:40 Mark Brown
2013-11-25 21:10 ` Linus Torvalds
0 siblings, 1 reply; 8+ messages in thread
From: Mark Brown @ 2013-11-25 17:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Liam Girdwood
[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/regulator-v3.13-rc1
for you to fetch changes up to 90ba0813db2c96c82e9ba24f30fb96a24a2cd3a8:
Merge remote-tracking branch 'regulator/fix/pfuze100' into regulator-linus (2013-11-24 14:02:50 +0000)
----------------------------------------------------------------
regulator: Fixes for v3.13
A bunch of fixes, a few driver specific ones and a framework fix for
voltage enumeration on fixed voltage regulators which had previously
worked but had been misplaced during some refactoring causing problems
for users that needed to know the voltage.
----------------------------------------------------------------
Charles Keepax (1):
regulator: arizona-micsupp: Correct wm5110 voltage selection
Guennadi Liakhovetski (1):
regulator: fixed: fix regulator_list_voltage() for regression
Laurent Pinchart (1):
regulator: gpio-regulator: Don't oops on missing regulator-type property
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
Tim Harvey (1):
regulator: pfuze100: allow misprogrammed ID
drivers/regulator/arizona-micsupp.c | 54 ++++++++++++++++++++++++++++++++--
drivers/regulator/core.c | 3 ++
drivers/regulator/gpio-regulator.c | 7 ++++-
drivers/regulator/pfuze100-regulator.c | 12 ++++++--
4 files changed, 70 insertions(+), 6 deletions(-)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [GIT PULL] regulator updates for v3.13-rc1 2013-11-25 17:40 [GIT PULL] regulator updates for v3.13-rc1 Mark Brown @ 2013-11-25 21:10 ` Linus Torvalds 2013-11-26 0:39 ` Mark Brown 0 siblings, 1 reply; 8+ messages in thread From: Linus Torvalds @ 2013-11-25 21:10 UTC (permalink / raw) To: Mark Brown; +Cc: Linux Kernel Mailing List, Liam Girdwood 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [GIT PULL] regulator updates for v3.13-rc1 2013-11-25 21:10 ` Linus Torvalds @ 2013-11-26 0:39 ` Mark Brown 2013-11-26 2:50 ` Linus Torvalds 2014-01-21 19:16 ` Linus Torvalds 0 siblings, 2 replies; 8+ messages in thread From: Mark Brown @ 2013-11-26 0:39 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Liam Girdwood [-- Attachment #1: Type: text/plain, Size: 1672 bytes --] On Mon, Nov 25, 2013 at 01:10:01PM -0800, Linus Torvalds wrote: > 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. Yes, it's a more accurate reflection of what I'm doing since none of the individual merges is a meaningful stage in development - either the topics get used or the final for-linus and for-next merges get used but not anything in between. In fact my script originally started off doing octopus merges but then Takashi complained at me saying you'd get annoyed so I switched to the stack of merges. > 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.. If you're OK with octopus merges for things like this I'll definitely take another look at using them, the enormous stack of merge commits always looks noisy to me in the logs and pull requests and for things like driver updates there's unlikely to be much doubt about which branch it was if there's a problem. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [GIT PULL] regulator updates for v3.13-rc1 2013-11-26 0:39 ` Mark Brown @ 2013-11-26 2:50 ` Linus Torvalds 2014-01-21 19:16 ` Linus Torvalds 1 sibling, 0 replies; 8+ messages in thread From: Linus Torvalds @ 2013-11-26 2:50 UTC (permalink / raw) To: Mark Brown; +Cc: Linux Kernel Mailing List, Liam Girdwood On Mon, Nov 25, 2013 at 4:39 PM, Mark Brown <broonie@kernel.org> wrote: > > If you're OK with octopus merges for things like this I'll definitely > take another look at using them, the enormous stack of merge commits > always looks noisy to me in the logs and pull requests and for things > like driver updates there's unlikely to be much doubt about which branch > it was if there's a problem. Yeah, I'm definitely ok with octopus merges, and I do them myself occasionally (especially with the -tip tree, which I get as many separate pull requests - see for example commit 669fc2f0c70a). And various maintainers use them too - Ingo does them for x86, Russell King does them for ARM, Roland Dreier for infiniband, Paul McKenney for rcu stuff, etc etc. Len Brown used to do them for ACPI all the time. But I do ask people to use them judiciously. Octopus merges are good for the "many small topic branches" kind of thing. But they should generally be avoided for big merges. Obligatory git trick of the day: git rev-list --parents HEAD | egrep '^.{128}' | cut -d' ' -f1 | git log --no-walk --stdin --oneline shows you the octopus merges. A couple of the older ones are bogus and come from the bad old days when git didn't properly filter parent lists, so there are redundant parents making a commit _look_ like an octopus merge even though it's really just merging one branch. Maybe Takashi hit one of those bugs back when.. Linus ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [GIT PULL] regulator updates for v3.13-rc1 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 ` (2 more replies) 1 sibling, 3 replies; 8+ messages in thread From: Linus Torvalds @ 2014-01-21 19:16 UTC (permalink / raw) To: Mark Brown; +Cc: Linux Kernel Mailing List, Liam Girdwood On Mon, Nov 25, 2013 at 4:39 PM, Mark Brown <broonie@kernel.org> wrote: > > If you're OK with octopus merges for things like this I'll definitely > take another look at using them, the enormous stack of merge commits > always looks noisy to me in the logs and pull requests and for things > like driver updates there's unlikely to be much doubt about which branch > it was if there's a problem. Christ. When you start doing octopus merges, you don't do it by half measures, do you? I just pulled the sound updates from Takashi, and as a result got your merge commit 2cde51fbd0f3. That one has 66 parents. That kind of merge either needs to be split up, or gitk needs to be made better about visualizing it, because it ends up being *so* wide that the history is hard to read. I think you'll find that having that many parents also breaks old versions of git. Anyway, I'd suggest you try to limit octopus merges to ~15 parents or less to make the visualization tools not go crazy. Maybe aim for just 10 or so in most cases. It's pulled, and it's fine, but there's clearly a balance between "octopus merges are fine" and "Christ, that's not an octopus, that's a Cthulhu merge". Linus ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [GIT PULL] regulator updates for v3.13-rc1 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 2 siblings, 0 replies; 8+ messages in thread From: Mark Brown @ 2014-01-21 20:31 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Liam Girdwood [-- Attachment #1: Type: text/plain, Size: 1809 bytes --] On Tue, Jan 21, 2014 at 11:16:57AM -0800, Linus Torvalds wrote: > On Mon, Nov 25, 2013 at 4:39 PM, Mark Brown <broonie@kernel.org> wrote: > > If you're OK with octopus merges for things like this I'll definitely > > take another look at using them, the enormous stack of merge commits > > always looks noisy to me in the logs and pull requests and for things > > like driver updates there's unlikely to be much doubt about which branch > > it was if there's a problem. > Christ. When you start doing octopus merges, you don't do it by half > measures, do you? :) It seems Takashi was right then. > That kind of merge either needs to be split up, or gitk needs to be > made better about visualizing it, because it ends up being *so* wide > that the history is hard to read. > I think you'll find that having that many parents also breaks old > versions of git. > Anyway, I'd suggest you try to limit octopus merges to ~15 parents or > less to make the visualization tools not go crazy. Maybe aim for just > 10 or so in most cases. Ah, I'd not noticed that one - I tend to find gitk output pretty hard to work with at the best of times once you hit lots of merges in a short time unless I limit it to particular subsets of code and once there's filtering it seems to cope well with both approaches (modulo the detail on the final merge commit). Long lived branches that go from -rc1 to the next merge window aren't at all friendly to visualisation tools. I can easily limit it, anyway. Or another option would be to have a branch which collects the merges incrementally rather than respining them all the time (but has no development itself) - I *think* that may be a bit more friendly to visualisation tools if done right but I seem to recall that such integration only branches were frowned upon? [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [GIT PULL] regulator updates for v3.13-rc1 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 2 siblings, 0 replies; 8+ messages in thread From: Takashi Iwai @ 2014-01-23 8:27 UTC (permalink / raw) To: Linus Torvalds; +Cc: Mark Brown, Linux Kernel Mailing List, Liam Girdwood At Tue, 21 Jan 2014 11:16:57 -0800, Linus Torvalds wrote: > > On Mon, Nov 25, 2013 at 4:39 PM, Mark Brown <broonie@kernel.org> wrote: > > > > If you're OK with octopus merges for things like this I'll definitely > > take another look at using them, the enormous stack of merge commits > > always looks noisy to me in the logs and pull requests and for things > > like driver updates there's unlikely to be much doubt about which branch > > it was if there's a problem. > > Christ. When you start doing octopus merges, you don't do it by half > measures, do you? > > I just pulled the sound updates from Takashi, and as a result got your > merge commit 2cde51fbd0f3. That one has 66 parents. > > That kind of merge either needs to be split up, or gitk needs to be > made better about visualizing it, because it ends up being *so* wide > that the history is hard to read. Yep, sorry, it's my fault that I overlooked Medusa there. I usually check with gitk, but at this time, I checked the results only via --no-merges option for concentrating on the real changes. Now I looked at it, and I was turned into sto..n...e...... Takashi > I think you'll find that having that many parents also breaks old > versions of git. > > Anyway, I'd suggest you try to limit octopus merges to ~15 parents or > less to make the visualization tools not go crazy. Maybe aim for just > 10 or so in most cases. > > It's pulled, and it's fine, but there's clearly a balance between > "octopus merges are fine" and "Christ, that's not an octopus, that's a > Cthulhu merge". > > Linus > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [GIT PULL] regulator updates for v3.13-rc1 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 2 siblings, 0 replies; 8+ messages in thread From: H. Peter Anvin @ 2014-01-24 0:04 UTC (permalink / raw) To: Linus Torvalds, Mark Brown; +Cc: Linux Kernel Mailing List, Liam Girdwood On 01/21/2014 11:16 AM, Linus Torvalds wrote: > On Mon, Nov 25, 2013 at 4:39 PM, Mark Brown <broonie@kernel.org> wrote: >> >> If you're OK with octopus merges for things like this I'll definitely >> take another look at using them, the enormous stack of merge commits >> always looks noisy to me in the logs and pull requests and for things >> like driver updates there's unlikely to be much doubt about which branch >> it was if there's a problem. > > Christ. When you start doing octopus merges, you don't do it by half > measures, do you? > > I just pulled the sound updates from Takashi, and as a result got your > merge commit 2cde51fbd0f3. That one has 66 parents. > For sheer amusement value: the tip-bot uses a private git tree to keep track of what it has mailed and not mailed. At least once it produced a 243-input octopus merge. -hpa ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-01-24 0:05 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-11-25 17:40 [GIT PULL] regulator updates for v3.13-rc1 Mark Brown 2013-11-25 21:10 ` Linus Torvalds 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
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.