2

From the main repository on github, I created a fork on github and I keep the master branch of my fork up to date with the main repository by doing:

git checkout master
git pull upstream master
git push

where upstream is set to the URL of the main repository.

I do this on the command line. It might be nice to be able to do that from within magit (emacs) but that isn't my question right now.

I then make a pull request by doing something like:

git checkout -b new-branch
... create changes including commits within emacs ...
git push --set-upstream origin new-branch

then go to github and make the pull request via its GUI. I'm fine with the GUI github part but if that can be simplified, I'm interested in that as well.

The last two git commands is what I'd like help with the most. I've read the documentation but find it hard to follow.

I have magit 2.12.1 and git 2.17.2 but I'm happy to update either if that will help. Also, I realize that the above sequence may not be optimal so I'm open to changing the sequence.

1

With magit, I would start the process with M-x magit-status or however you prefer to get there. In the status buffer press b to bring up the branching menu, and then press c to create a new branch. A dialog will ask you where to branch from (defaulting to the current branch), and for the name of your new branch.

Do your work, and go back to the status buffer when done. Assuming you have your commits ready, press P to enter the push menu. From there, u will push to "upstream" which, like Tarsius said, is configured to where you cloned it from: origin/master. pressing p will push to a remote you can choose or configure. Once the remote is configured, pushing is as simple as P p.

I think the way your scenario is intended to be setup is that you clone the public repository to your local machine. That is upstream origin/master. Then you setup your fork to be your remote for pushing. Eventually you use github to make a pull request to upstream. Pull requests aren't really a part of git, they're a github thing, so as far as I know there isn't an interface for PRs. EDIT: now I know that Magit Forge is a thing.

Assuming you start with that remote setup, you can do first part of your question, syncing with upstream, like this:

  • Press b b and select master
  • Press F u to pull upstream
  • then P p to push to your remote fork
  • Your reply helped. It seems I have been using git / magit in an unusual way. I want to try and re-read the two-branches page of the Magit Info. I truly do appreciate your an Tarsius' help. – pedz Jan 29 at 16:25
  • To be honest, I didn't realize I was doing it wrong either. I have had the same setup as you with a GitHub upstream and my fork as origin. So we both learned something thanks to Tarsius. – shoshin Jan 29 at 17:51
1

The convention is to name the upstream repository origin. I think it is a good idea to stick to that convention, but I guess naming the upstream repository upstream also makes a lot of sense. However it is a bad idea to name a repository that is not the upstream origin. Doing that is really confusing.

When you clone a repository using git clone <upstream-url>, then that automatically creates a local branch named master which has origin/master set as its upstream. If you insist on naming that remote upstream, then you can do the same using git clone --origin upstream <upstream-url>.

To get your local version of another remote branch, e.g. origin/new-feature use b c origin/new-feature RET RET. Before you do that you should git config --global branch.autoSetupMerge always once. After doing that the upstream branch is automatically set when creating a new branch from an existing remote branch. Without that this is only done if the source is a local branch. I.e. the default value of that variable is a really bad one.

Now to your question...

Do not change the upstream when pushing. A branch can have two other branches associated with it the upstream (the branch on top of which you add new commits and into which you would like your changes to be eventually merged) and the push target (the branch where you push your changes so that you can ask the maintainer to merge it (into the upstream)).

The manual has information about the two remotes.

To push to the push remote, i.e. your badly named fork origin, type p p origin RET. You only have to type the origin once per branch, afterwards you can just use p p. This assumes that you have set

  • Thanks for your nice walk through. Apparently you missed some text when pasting your answer [This assumes that you have set `...?]. – clemera Jan 24 at 11:19
  • I think you might have missed my first paragraph (or I am missing your point ... one of the two). My origin points to my fork of the repository and upstream points to the public repository. So... to repeat: I got to github (which I'll call the original repo) and make a fork which I'll call "my fork". I then go to my fork and get the URL and do a clone of that URL. Then I add a remote called upstream that points back to the original repo. To keep the master branch of my fork up to date with the original, I do the three steps at the top. – pedz Jan 24 at 16:26

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.