[SCM] supercollider/master: Imported Upstream version 3.6.1~repack

Felipe Sateler fsateler at debian.org
Thu Dec 27 13:05:33 UTC 2012


On Thu, Dec 27, 2012 at 7:03 AM, Dan S <danstowell+debmm at gmail.com> wrote:
> 2012/12/26 Felipe Sateler <fsateler at debian.org>:
>> On Wed, Dec 26, 2012 at 4:21 PM, Dan S <danstowell+debmm at gmail.com> wrote:
>>> 2012/12/26 Felipe Sateler <fsateler at debian.org>:
>>>> On Wed, Dec 26, 2012 at 3:09 PM, Dan S <danstowell+debmm at gmail.com> wrote:
>>>>> 2012/12/26 Felipe Sateler <fsateler at debian.org>:
>>>>>> On Wed, Dec 26, 2012 at 7:19 AM, Dan S <danstowell+debmm at gmail.com> wrote:
>>>>>>> 2012/12/25 Felipe Sateler <fsateler at debian.org>:
>>>>>>>> On Thu, Dec 20, 2012 at 5:12 PM,
>>>>>>>> <danstowell-guest at users.alioth.debian.org> wrote:
>>>>>>>>>
>>>>>>>>> The following commit has been merged in the master branch:
>>>>>>>>> commit b058aafc3bfcd2b94317654ff3306700f558c61b
>>>>>>>>> Author: Dan Stowell <danstowell at users.sourceforge.net>
>>>>>>>>> Date:   Thu Dec 20 19:29:29 2012 +0000
>>>>>>>>>
>>>>>>>>>     Imported Upstream version 3.6.1~repack
>>>>>>>>
>>>>>>>> It seems this is not a merge from the upstream branch.
>>>>>>>>
>>>>>>>> This can be fixed, but the history would be rewritten and clones would
>>>>>>>> break. I think it is worth it, though.
>>>>>
>>>>> (Rewriting the history is fine by me btw)
>>>>
>>>> OK, you can do this as follows (I don't think I'll get access to my
>>>> usual computer this week):
>>>>
>>>> git rebase -i some-commit-before-the-bad-non-merge
>>>> # Select to edit the previous commit to the non-merge, and delete the non-merge
>>>> # When git drops you in a shell to edit the command, do
>>>> git merge upstream/3.6.1_repack
>>>> git rebase --continue
>>>>
>>>>
>>>> This should leave you the correct history.
>>>
>>> Thanks, this works for me locally - but I am not allowed to push
>>> non-fast-forward to the remote server (as far as I know)
>>
>> You can use git push -f to remove the check
>
> OK, though it still refuses until I pull again, first. If I pull with
> rebase it goes back to the previous un-fixed state. If I pull without
> rebase I get this slightly odd state with parallel branches getting
> merged:
> http://paste.debian.net/219521/
> If this is OK to push, please confirm and I will do.

No, I think this history confuses even more. Strange that you cannot
do a git push -f. What happens if you try pushing only that branch?
(git push -f origin master:master)

--

Saludos,
Felipe Sateler



More information about the pkg-multimedia-maintainers mailing list