[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Git policy for kde-baseapps?
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2012-09-27 11:31:29
Message-ID: CA+XidOF-844_-QUexVwP8jXLtj8Zvg7oEWUEcMU5hWpBAduB9A () mail ! gmail ! com
[Download RAW message or body]

On Thu, Sep 27, 2012 at 6:37 PM, Frank Reininghaus
<frank78ac@googlemail.com> wrote:
> Hi,

Hi,

>
> 2012/9/26 Dawit A:
> [...]
>>> > How can that be resolved or do we live with the duplicate log entries ?
>>>
>>> I don't know how to avoid a duplicate entry in that case. But given
>>> the big mess of duplicate entries that we had in the past every time
>>> someone decided to merge, I think that a single duplicate entry is
>>> something that we can probably live with.
>>
>>
>> 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.

>
> But this is just my understanding of "git rebase". If someone with
> more git knowledge knows better, please correct me!
>
> Cheers,
> Frank

Regards,
Ben

> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]