[TEST] Duplicate of #8357, but using octopus merge #8358
Conversation
### Description The VTOR reserves the lowest 7 bits. This PR changes the round up behavoir of the application offset to make sure that the address used for the in-flash vector table always ends in 7 0's. Fixes ARMmbed#7392 ### Pull request type [x] Fix [ ] Refactor [ ] Target update [ ] Functionality change [ ] Breaking change
### Description The netbeans exporter was being inconsistant with it's invocation of the C pre-processor on the linker script: the C pre-processor was always invoked from `$PATH` where as the rest of the tools were invoked as configured by the tools. This changes the invocation of CPP to match the rest of the tools: heed the conifguration. Fixes ARMmbed/mbed-cli#663 ### Pull request type [x] Fix [ ] Refactor [ ] Target update [ ] Functionality change [ ] Breaking change
### Description
Exporting to GNU ARM Eclipse, E2 Studio, and other exclude-based IDEs
currently generats unusable project files online. This is because the
list of directories ignored in the scan is inconsistant about what sort
of paths are used: logical paths, or phisical paths. This patch makes
all paths in ignored_dirs logical. This should fix the excluding tags
in these project files.
### Pull request type
[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Breaking change
### Description
I noticed that there was quite a bit missing from the mbed2 release of
the microbit today. That's because the microbit uses ARM by default and
the GCC_ARM small library. The release script was trying to release for
ARM using scan rules for uARM. Turns out we're stuck with 2 configuration
parameters for the same thing: `default_lib` for GCC and `default_toolchain`
for ARM. Dang
### Pull request type
[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Breaking change
… and 'pr8248' into omnimerge-test-1
|
/morph build |
Build : FAILUREBuild number : 3307 |
|
Closing since working with |
|
Octopus merge or not, I don't think I'd want to use "git bisect" to try to figure out which PR was causing failure. You're likely to end up trying to test the midpoint of a PR, and I doubt many PRs are properly bisectable like that, sadly. I think you'd be better off manually bisecting by halving the number of PRs in the octopus merge. |
|
What I just found out with this PR, and #8357 before its update, was that git bisect was able to bisect along the merge commits instead of each PR's individual commits. Finding the problem PR was surprisingly trivial. |
|
Bisect is more likely to hit a merge commit if you have more of them, so you're less likely to hit mid-points. But it will still test the mid PR points, or try to. Don't think you can tell it to do a "first-parent bisection" down just the merge commits, or that it will even test them first. |
|
I guess you can say "skip" every time it stops on a non-merge commit, but then you're just manually persuading it to do the "half the PRs at a time thing" you could have done yourself. It really wants to bisect the total number of commits. People discussing this issue here: https://stackoverflow.com/questions/5638211/how-do-you-get-git-bisect-to-ignore-merged-branches |
Description
Duplicate of #8357, but generated using an octomerge instead.
Pull request type