Rebase of kopete branch and push it to master

[Luigi Toscano]

Pali Rohár ha scritto:
> On Tuesday 16 January 2018 23:05:42 Albert Astals Cid wrote:
>> El dimarts, 16 de gener de 2018, a les 0:45:27 CET, Pali Rohár va escriure:
>>> On Tuesday 16 January 2018 00:32:44 Albert Astals Cid wrote:
>>>> El dimarts, 16 de gener de 2018, a les 0:09:50 CET, Pali Rohár va 
>> escriure:
>>>>> On Tuesday 16 January 2018 00:06:29 Albert Astals Cid wrote:
>>>>>> So is the problem:
>>>>>>  a) that you could not push that master-kf5 to master
>>>>>
>>>>> Problem is really a).
>>>>
>>>> Why is that? You said master-kf5 is just a rebase of kf5 on top of master,
>>>> what's the problem of pushing that branch?
>>>
>>> Because it does not work.
>>>
>>> remote: Push declined - excessive notifications would be sent
>>> remote: Please file a KDE Sysadmin bug to continue
>>>
>>> Therefore I opened sysadmin ticket T7642 and I was told that I should
>>> discuss about it on kde-core-devel.
>>
>> Please someone correct me, but that has nothing to do with rebasing no?
> 
> Let me explain it again. Under "rebase" I mean result of operation
> git rebase. Under "push" I mean result of operation git push.
> 
> I took branch kf5 from main kopete repository. Then I rebased it on top
> of master and pushed to my personal cloned git repository into branch
> master-kf5.
> 
> Now I wanted to push this master-kf5 into branch master to main kopete
> repository. And push failed.

As explained by Ben, it is by design: a push like this is usually not what the
developer wants, and only in rare cases it makes sense (usually an import, or
when codes was shuffled around in the early times of Frameworks).

> 
> Strictly speaking it git rebase --onto & git push. But with fact that it
> does not use any force push (therefore no history overwrite).

This is were the opinion differs. It is history rewriting for me: looking back
at what happened in the KF5 port, people will see a big set of commits pushed
on top of master, without understanding when some change happened in
comparison to the others, because all the intermediate merges are lost. The
information conveyed by two parallel branches with cross-merges is lost.

I understand they wrote that it was ugly - but it was what happened. Something
to not repeat, but now it is like this.

This is just for reference; a decision has been made.

-- 
Luigi