Stackplot - #818

Woah! Eight commits?!?? Anybody have any idea how I can fix this? Only the last two commits are relevant. The trisurf code was from and old pull request that was merged into master.

You could use interactive rebasing---something like:

git rebase -i HEAD@{8}

And then, in the interactive prompt, change pick to squash (or just s), for everything below the top commit. You'll also have to force a push to your github repo after making these changes.

That said, it's generally frowned upon to rebase after pushing changes to a remote (where other people could have already forked your repo, and then the fork will be completely off after the rebase). I doubt it's much of an issue here, but I just thought I'd mention it.

Hmmm, but then the trisurf merge would still be there, right?

Oh, so the trisurf merge adds code that you don't want to submit as part of the PR? In other words, you don't just want to collapse the commit message, but instead, ignore code-changes from those commits. Correct?

This stackoverflow response suggests creating a new branch based off of upstream/master and then cherry-picking the commits to add to the new branch (you'd replace the sha1 in the example with 3b383ee and ae76455). (Note: the response names the new branch upstream but you'd want to name it something else.) Also, you'd have to resubmit the PR using the new branch.

Yes and no. I had made a branch called trisurf and filed a pull request from it. That code was merged by Ben Root into upstream/master. Now, instead of deleting my local trisurf branch, I merged it into my master branch. Then when I fetched the upstream branch (which contained my changes anyway) I resolved all the conflicts using the '--theirs' strategy. So as far as I understand, the code in my local master branch and the code in the upstream/master branch is identical. I guess when I created the stackplot branch and filed this PR, it wants to merge everything where the commit histories differ. That stack overflow answer would work as I want it to, thanks for that.

How would I fix my master branch so the histories match, too? Would this do what I expect?

git checkout master; git revert HEAD~9; git fetch upstream; git merge upstream/master

Damon McDougall
d.mcdougall@warwick.ac.uk
http://damon.is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Saturday, 7 April 2012 at 12:36, tonysyu wrote:

Oh, so the trisurf merge adds code that you don't want to submit as part of the PR? In other words, you don't just want to collapse the commit message, but instead, ignore code-changes from those commits. Correct?

This stackoverflow response suggests creating a new branch based off of upstream/master and then cherry-picking the commits to add to the new branch (you'd replace the sha1 in the example with 3b383ee and ae76455). (Note: the response names the new branch upstream but you'd want to name it something else.) Also, you'd have to resubmit the PR using the new branch.

---

Reply to this email directly or view it on GitHub:
#818 (comment)

Alright, let's try this again. This time with a bajillion commits.