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

[Felipe Sateler]

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.

>
>>> Here is what I did. I believe I acted correctly. Please could you tell
>>> me what I did wrong:
>>>
>>> #  (first go to sf.net, find the MD5 for the latest version, put the
>>> MD5 and version in debian/rules)
>>> # (then "dch -i" and add an entry for the version number, with ~repack added)
>>> fakeroot debian/rules get-orig-source
>>> git-import-orig --pristine-tar -v ../tarballs/supercollider_3.6.1~repack
>>
>> This looks correct (assuming the missing .orig.tar.gz is a typo).
>> (also, the --pristine-tar is unnecessary because it is already defined
>> in debian/gbp.conf)
>>
>> Do you have any config in ~/.gbp.conf? Or git configuration
>> (~/.gitconfig, .git/config, /etc/gitconfig)? It seems like the
>> upstream branch was rebased on top of master instead of being merged.
>
> I do, but just colouring and aliases, nothing intricate.
> http://paste.debian.net/219320/

OK, nothing wrong here.

>
>>> PS I've been trying so hard to do it exactly by the rules and it seems
>>> every time the results are not as desired. If the tools make it so
>>> easy to fail, how will a newcomer learn to use them?
>>
>> It is indeed unfortunate that you've had trouble with the gbp tools.
>> However, it is not that common (otherwise we wouldn't use them!).
>> Hopefully we can diagnose the root cause of this failure so that it
>> doesn't happen again.
>
> Thanks, that's somehow good to know!
>
> I have had an idea for what may be the problem: after importing, I did
> some tweaking, and then used things like "git rebase -i HEAD^^" to
> make my commits more neat. I guess it's possible that I accidentally
> included the mergecommit in a rebase, which might then have replayed
> the merge as if it was something brand new.

Indeed, this is it! By default, rebase doesn't respect merges, which
can be annoying. There is the -p flag, but it can produce bad results
as well (if done at the same time as -i), so I prefer to avoid rebases
with merges in the middle.


--

Saludos,
Felipe Sateler