Review Request: Make KAuth ready for frameworks + API Changes

[Dario Freddi]

Il 31 marzo 2012 21:03, Stephen Kelly <steveire at gmail.com> ha scritto:
>
> Now I'm confused.
>
>>> Stephen Kelly wrote:
>>>     It was rebased onto some relatively recent commit, but not the tip of
>>>     the branch.
>
> You disagreed with what I said:
>
>>  - Given that the branch was rebased on top of the last frameworks' commit
>>  (as you can see from the log),
>
> ... actually I don't see that in the log. Here's what I see:
>
> http://i.imgur.com/xhbCC.png
>
> Do we have a difference in definitions, or is something else causing the
> confusion?

gitk indeed has a screwy visualization in there. Although, if you look
at the information in the merge commit, you'll see:

Parent: 4f9bf523bdb3f274f533d1dad2657537812d8c61 (match only the first
filter, if there are several matching (fdo#48054))

Which is indeed the last commit of frameworks before the rebase happened.

>
>> - Last but not least, looking just at the merge commit shows you the full
> diff the branch introduced - in such a case, for example, is incredibly
> useful to track all of the API changes at once. Yes, you could have used git
> diff <merge commit> <first commit before the rebased branch> and it would
> have had the same effect, but the approach is more clean
>
> I tried this with gitk and git show. Neither worked as you describe.

You can see this for example here:
http://quickgit.kde.org/index.php?p=kdelibs.git&a=commit&h=1f6e4685b66090c3e99edf511f38b44da2dff024

>
>> Starting from the point that this discussion is mostly about one's own
>> taste (and again, that's why we NEED a clear policy), my reason for doing
>> this is that:
>
> Policies won't help.
>
> Only technical measures like not accepting pushes with merges, except
> between release-lines (master, 4.8 branch etc) would work, if such a thing
> would be decided on, or if your workflow became policy, only accepting
> pushes with only merge commits on release-line branches.

Exactly, I agree with this. Remains that we still have to settle on one first :)

>
> I doubt such a thing could be both decided on though. I can imagine what the
> hook would look like in both cases.
>
> More importantly though, you seem to have broken the frameworks branch.

True, sorry about that. This is fixed now.