stable-tracking/16e183d: jbt6k74.c:558: error: implicit declaration of function 'jbt6k74_display_onoff'

[lindi]

stable-tracking 16e183d5b9b5e0bc6d14877a8815e91d9000792e built with

git pull
make ARCH=arm clean
cp arch/arm/configs/gta02-moredrivers-defconfig .config
./build dummy

seems to fail to build with

drivers/video/display/jbt6k74.c:558: error: implicit declaration of function 'jbt6k74_display_onoff'

[andy]

What about andy-tracking?

Is there any particular reason you're sticking with stable-tracking and not andy-tracking? I am not routinely building stable-tracking right now.

[lindi]

Only reason is lack of time. I have not learned git enough to figure out how to see changes between stable-tracking 80f4b57fef5dcffb (what I currently use) and andy-tracking 9b2a35dd616a9fbe.

git diff 80f4b57fef5dcffb 9b2a35dd616a9fbe

works but I'd like to see this in the format of 'git log' if possible. I am learning git more and more but it takes time :-)

[andy]

Yes git diff is the only tool I know about for this as well.

Before we changed to having trees with history, you could actually see stable-tracking head if you scrolled down from andy-tracking head, then you knew what the additional patchset was. But with the history, that is hidden and the branches publicly sync by merge patches that are mini git diffs. I think between the two choices having the history is going to be generally more useful but your point is fair enough.

I still have that kind of branch here locally, I can publish it in addition to the history branches but probably it will make some peoples' heads explode to see two branches for each official one.

For now stable-tracking is just a stake in the ground for a future where we got everything upstream, I am only building andy-tracking regularly.

[mrmoku]

gitk stable-tracking..andy-tracking -- drivers/video/display

nicely shows all commits between the two branches that touched files in drivers/video/display.

for git log just put .. between the two revisions:

git log 80f4b57fef5dcffb..9b2a35dd616a9fbe

[lindi]

git log 80f4b57fef5dcffb..9b2a35dd616a9fbe

shows 532 commits here, have there really been so many changes?

[andy]

80f4b5... was before the change to history I think, it means that it can have exposed the pop, rebase, push business that actually underlies the rebasing: maybe that's how we get 532 commits.

Thanks for the tip about gitk mrmoku.

I think if you can deal with the jump over to andy-tracking (it means taking on Balaji's regulator stuff) then it will be a lot easier going on since the history stuff is then working for you, there will be only a linear list of commits on andy-tracking to look at for changes.

[andy]

It seems this is resolved by using andy-tracking, we will have to get stable-tracking to build standalone at some point but it isn't critical today.