On Wed, Dec 26, 2012 at 3:09 PM, Dan S <[email protected]> wrote: > 2012/12/26 Felipe Sateler <[email protected]>: >> On Wed, Dec 26, 2012 at 7:19 AM, Dan S <[email protected]> wrote: >>> 2012/12/25 Felipe Sateler <[email protected]>: >>>> On Thu, Dec 20, 2012 at 5:12 PM, >>>> <[email protected]> wrote: >>>>> >>>>> The following commit has been merged in the master branch: >>>>> commit b058aafc3bfcd2b94317654ff3306700f558c61b >>>>> Author: Dan Stowell <[email protected]> >>>>> 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 _______________________________________________ pkg-multimedia-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
