I don't know why static-test failed here while I can merge this branch on my local setup...

Might be a problem with the git version, on my macOS with git 2.18 rebase is working fine - but Murdock and Travis use git version 2.17 (or older). @dylad IIRC you had a problem with git before updating too, right?

mhm strange on Fedora 27 with git version 2.14.4 it works, and on Raspbian with git version 2.11.0 too.

@kaspar030 any idea how to proceed or get over this git rebase problem?

Yes I confirm I cannot rebase with git 2.17.1 (default on ubuntu 18.04) I had to switch to version 2.18

I don't understand why Travis fails, I just started ubuntu:trusty in docker installed all packages according to our .travis.yml and then make static-test, which succeeded without errors (though some warnings for commit messages longer than 50 chars).

What is the git version used in Docker ?

@dylad 1.9.1 as in Travis,

BUT the problem is that Travis uses:

git clone --depth=50 https://github.com/RIOT-OS/RIOT.git RIOT-OS/RIOT
git fetch origin +refs/pull/9539/merge
git checkout -qf FETCH_HEAD

using the commands a subsequent git rebase master fails.

while rebase works when doing

git clone https://github.com/RIOT-OS/RIOT
cd RIOT
git checkout new_i2c_if
git rebase master

but it does not with this FETCH_HEAD stuff

@smlng Then we must change the behaviour of Travis ?

I don't know how and if it makes sense

interesting: using the command from travis rebase also fails on macOS with git version 2.18

its a bit weird, that there are diffs between the new_i2c_if branch and the +refs/pull/9539/merge Travis is using, despite the fact that this PR is based on the named branch.

Maybe I did something wrong when submitting this PR on my side ?

I don't think so, because GitHub does not report any conflicts for this PR, its mergeable theoretically - but its blocked due to missing review and missing murdock okay 😩

@kaspar030 @miri64 We really need your holy words here :(

@dylad it looks like you didn't rebase the branch against the latest master, can you rebase the new_i2c_if branch again and push the update. Its best you make a clean checkout eg. in /tmp for this. Maybe this helps, because ideally if the branch is up to date with latest master the rebase should do nothing (ie. git saying "HEAD is up to date.").

@smlng I'll try but when I rebased the branch yesterday, I'm sure I was on the lastest (at this time) master already.

Looks like this is worse...

not really, but it didn't help either ...

@smlng Could you detailled the steps you used to reproduce the issue on Travis on your side please ?
I'll retest over and over on my side with different git version.

I retested locally with :

git clone --depth=50 https://github.com/RIOT-OS/RIOT.git RIOT-OS/RIOT
git fetch origin +refs/pull/9539/merge
git checkout -qf FETCH_HEAD

Indeed, it fails with
git rebase master
but this works with
git rebase master --preserve-merges

using git 1.7.1
using git 2.17.1

@dylad (not so) funny side note, when I do

git fetch origin +refs/pull/9539/merge
git checkout -qf FETCH_HEAD
git rebase master

it fails but when I do

git fetch origin +refs/pull/9539/merge
git checkout -qf FETCH_HEAD
git rebase -i master
          ^^^^

and do nothing on the interactive merge just quit the editor (vim) with :q directly ... it works?! 😦

It seems there is a difference in the default merge strategy or something like that, so we might be able to fix this on Murdock, at least.

@smlng I'm completely lost with this PR... Why can we merge all the PRs we want except this one ?!

there is a merge conflict during the rebase - at least how Travis and Murdock do the rebase. I don't think its git version related.

@smlng So you think we should change the behaviour of Murdock/Travis just because of this PR ?

closed in favour of (working) #9548

Sorry, old habbit ^^"

@miri64 You can delete this branch if you want,
I plan to cleanup all the mess I introduce after the I2C rework.