KDevelop 4.3 branch screwed again?

[Nicolás Alvarez]

2012/6/22 Nicolás Alvarez <nicolas.alvarez at gmail.com>:
> 2012/6/10 Milian Wolff <mail at milianw.de>:
>> On Sunday 10 June 2012 17:39:25 Andreas Pakulat wrote:
>>> Hi,
>>>
>>> On Sun, Jun 10, 2012 at 10:17 AM, Andreas Pakulat <apaku at gmx.de> wrote:
>>> > Hi,
>>> >
>>> > On Sun, Jun 10, 2012 at 1:20 AM, Friedrich W. H. Kossebau <
>>> >
>>> > kossebau at kde.org> wrote:
>>> >> Hi,
>>> >>
>>> >> after lot of month I tried to build the current 4.3 branch (on commit
>>> >> 5c288e2014c043593f8c6385b2aefb221615a652) and I am hitting a build
>>> >> problem in
>>> >> kdevelop/languages/cpp/cpplanguagesupport.cpp (see attached log for full
>>> >> output). Any idea what is wrong for me?
>>> >>
>>> >> Yes, deleted any 4.3 branch I had locally. But refetching did not improve
>>> >> things.
>>> >>
>>> >> The looking at the stuff on the central repo like
>>> >>
>>> >> https://projects.kde.org/projects/extragear/kdevelop/kdevelop/repository/
>>> >> revisions/4.3/entry/CMakeLists.txt I wonder about the KDEVELOP_VERSION,
>>> >> does not look correct. The needed KDevPlatform version 1.3.60 also looks
>>> >> strange.
>>> >
>>> > Can't look at this right now due to the identity.kde.org downtime, my
>>> > local checkout from May 12th, however still shows a separate 4.3 head. So
>>> > if there is a problem it was introduced only recently.
>>>
>>> Hmm, seems like someone did a reset at some point, I can see this in the
>>> history:
>>>
>>> The last commit into the original 4.3 branch following the v4.3.1 tag
>>> (which was still ok) is:
>>> 6b95b832d72696df0278ac7b9d290c96b798ef07
>>>
>>> That follows a merge of 4.3, probably into master. And then next there are
>>> a few scripty commits (1e692b9d495d9bfd3af54f2769d4c764e7e197d7 and
>>> following) and then milian
>>> comitted based on that last scripty commit again
>>> (86f4848f9f6324540c0ca9c70dfd81ff0e6b1cfc) . There's been a few more
>>> commits and ultimately this branch leads to the current 4.3 tip
>>> (5c288e2014c043593f8c6385b2aefb221615a652).
>>>
>>> So I guess 4.3 needs to be reset
>>> to 6b95b832d72696df0278ac7b9d290c96b798ef07 and then each of the following
>>> commits on the wrong 4.3 branch need to be cherry-picked, except for the
>>> scripty-ones (those will just be done again by scripty on its next run).
>>>
>>> I'm cc'ing milian explicitly to make him aware of this.
>>
>> Hey, thanks for the notification.
>>
>> Can anyone look into this? PovAddict?
>
> This seems to be partly my fault. I'm still investigating what exactly
> went wrong.
>
> Fixing it looks tricky, because many commits were done on top of the
> bad merge, and the 4.3 branch was merged into other branches. If I fix
> only 4.3, many commits will be duplicated (once in the fixed 4.3
> branch, and again in the non-fixed 4.3 as merged in the other
> branches)...

After looking at the server logs, here's the whole story:

- The 4.3 branch was at fd5ea0 (which is coincidentally the commit
tagged as v4.3.1).

- Milian accidentally pushed 5799ab ("Fix gcc include-path…") into
both master and 4.3, despite being created over master history. The
server allowed this with no errors, because 4.3 had been merged into
master recently, so this was a proper descendant of the previous 4.3
branch state (otherwise it would have needed a force-push). This is
similar to when Aleix accidentally merged master into 4.3 rather than
the other way around.

- I force-pushed to undo this push and reset 4.3 back to fd5ea0. Repo
is now fixed.

- Milian pushed 6b95b8 into 4.3. This was a proper cherry-pick of
5799ab over 4.3 history. Repo is still OK.

- However, Scripty had already fetched the repository between Milian
mis-pushing and me fixing it. So on its next run, with its local
branch pointing at 5799ab, it pulled from 4.3, merging 6b95b8 onto
5799ab, doing its translation-update commit on top, and pushing to
4.3. This essentially re-introduced the bad commit (5799ab), and the
master history attached to it, into 4.3.
Don't worry if you can't follow this part, the important thing is that
scripty re-pushed the bad commit I had removed.

- Scripty did a few more translation commits on top of the current
mess, reaching 60f2e5.

- I was notified of the problem with scripty, and reset the 4.3 branch
to 725213. *This is what went wrong*. I should have reset the branch
to fd5ea0 again instead. 725213 was a merge from 4.3 to master, pushed
into master, supposed to be only in master. I don't know if I
misunderstood the problem, the history graph, or if I simply
copy-pasted the wrong thing.

Since then, there have been 25 commits (11 of them from scripty)
pushed into 4.3, on top of 725213. In addition, 4.3 was merged into
master a few times, and master was also merged into the 'unittest' and
'file-templates' feature branches.

I can fix this by rebasing the 25 commits done after 725213 on top of
fd5ea0 instead. The problem is that due to the above-mentioned merges,
the commits in 725213..4.3 are also present in master, unittest, and
file-templates. I would have to rewrite all four branches... Fixing
4.3 alone would mean the full history would have duplicated commits,
and as soon as 4.3 is merged into master (which is supposed to happen
regularly), the log of master alone would show those duplicated
commits.

However, rebasing four public branches including master is obviously
problematic... Anyone who cloned or pulled since April(!) would be
"affected". Plus https://github.com/Gnurou/kdevelop which would need
rebasing on top of the new master too.

Suggestions, questions, sighs, finger-pointing welcome.

-- 
Nicolás