This seems to have fixed both problems. Thank you very much, Marcus
> On May 3, 2018, at 4:17 AM, Rainer Müller <[email protected]> wrote: > > On 2018-05-03 12:14, Marcus Calhoun-Lopez wrote: >> The only git commands I have been running (not in this order) are >> git pull --rebase upstream master >> git pull --rebase origin cargo-pg >> git pull --rebase origin master >> git push origin cargo-pg >> where >> cargo-pg is the name of my branch and upstream is >> git remote add upstream https://github.com/macports/macports-ports.git > > With 'git pull --rebase', you instruct git to take the specified remote > and put all commits that are not in the remote on top of the branch. > > git pull --rebase upstream master > This brought in new commits from the master branch and put the local > commits on top. This is what you wanted. > > git pull --rebase origin cargo-pg > This started with the cargo-pg branch, but then the new local commits > (that came from master, but are not yet on cargo-pg), were put on top. > Now you have the commits from cargo-pg first, then the commits that were > done on master. This is the wrong order and not what you wanted. > > Usually, you never want to rebase with anything else than > upstream/master. You always want to start with the state of upstream, > then put your new commits on top of that. You would first switch to the > branch you want to work on, then run rebase: > $ git checkout cargo-pg > $ git pull --rebase upstream master > > > After that advice for the future, there are two things to be fixed here. > One is your master branch and one is the cargo-pg branch. Let's start > with the cargo-pg branch. > > Switch to the branch and rebase again on top of the current state of > upstream/master. This will start with upstream, then put all local > commits on top. Although you had "cloned" commits from upstream/master > to this branch before, this will still do what you wanted. In case a > commit results in an empty patch (has been applied before), it will be > dropped during rebase. Therefore all the commits that are not meant to > be on this branch will be gone after running these commands. > > $ git checkout cargo-pg > $ git pull --rebase upstream master > (verify results in 'git log') > $ git push --force origin cargo-pg > > Now, let's go to the master branch. It is diverged because there is a > commit for octave on it, then lots of "cloned" commits from > upstream/master. Again, you can get rid of the "cloned" commits by > running rebase again. As this one commit for octave is also already in > upstream/master, there will be no local commits left after these commands: > > $ git checkout master > $ git pull --rebase upstream master > (verify results in 'git log', should be identical to upstream/master) > $ git push --force origin master > > > 'git push --force' is considered dangerous because it allows you push a > branch state that removes commits that were pushed previously. But > sometimes this is exactly what you need to clean up. > > 'git push --force' can only have unwanted effects when you are > collaborating with others. By changing the branch such that commits are > now missing, others might no longer be able to pull changes from the > branch. However, these are branches in your personal fork, so you can do > with the branches whatever you want. It is also unlikely that anyone > else has a clone of your repository. > > Hope this helps! > > Rainer
