Help with Pull Request

[Marcus Calhoun-Lopez]

This seems to have fixed both problems.

Thank you very much,
Marcus

> On May 3, 2018, at 4:17 AM, Rainer Müller <raimue at macports.org> 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