Git policy for kde-baseapps?

[Ben Cooksley]

On Fri, Sep 28, 2012 at 2:28 AM, Frank Reininghaus
<frank78ac at googlemail.com> wrote:
> Hi Ben,

Hi Frank,

>
> 2012/9/27 Ben Cooksley:
> [...]
>>>> Well, I found an answer to my own question at [1]. Basically, it says doing
>>>> a rebase of the branch with the master and merging afterwards will prevent
>>>> the duplicate log message:
>>>>
>>>> $ git co -b 4.9 origin/KDE/4.9
>>>> $ git co -b master origin/master
>>>> $ git rebase master 4.9
>>>> $ git co master
>>>> $ git merge 4.9
>>>>
>>>> Perhaps people with more intimate knowledge of git than I want to comment on
>>>> the validity of above steps ? However, it seems to work just fine when I
>>>> tested it against kde-baseapps:
>>>
>>> I think that this approach works fine for local branches, but can lead
>>> to serious problems when used for branches which exist already on the
>>> remote server.
>>>
>>> The problem is that "git rebase" changes the SHA1 hashes of all
>>> commits that are rebased. When this rebased branch is then pushed to
>>> the server (I don't know if that actually works without admin
>>> permissions), the hashes of the commits in the remote branch on the
>>> server and the hashes that the users who pulled earlier have in their
>>> local clones of the repository don't match any more. I think that
>>> users cannot pull the branch any more then without some manual hacking
>>> of the repository state.
>>
>> Due to this issue, mainline KDE git repositories do not permit force
>> pushes, unless a special exemption has been granted.
>> Force pushes also create issues for our commit hooks, which depend on
>> the sha hash not changing to detect commits already in the repository.
>
> Thanks for this information! Quick question: Could it be that some
> commit hooks are nonetheless executed when someone tries a force push,
> even though the commits do not reach the remote repository at all?
> This might explain why I sometimes receive commit mails for commits
> which do not exist at all, see, e.g.,

There are 3 different hooks which run on KDE repositories:
- Gitolite
- Our own auditing and notification hook
- A post-update hook which triggers the anongit update and build.kde.org builds

In the case of force pushes, Gitolite will stop them. A push will only
be successful once the first two hooks are completed (as the 3rd is a
post-update hook).

>
> http://lists.kde.org/?l=kde-commits&m=134632916023074&w=2
>
> Try clicking the link in that mail to see that the commit really does not exist.

That is concerning, I will have to talk to Vishesh to find out what
happened there. I cannot think of too many scenarios where an email is
sent, but the commit does not actually end up in the repository. As
emails are sent before the commits are accepted into the repository,
this is definitely a plausible scenario however.

>
> Best regards,
> Frank

Regards,
Ben

> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel