3

The story here is that I use magit at work, where our workflow involves the use of a preposterous number of branches on our central remote (used for various purposes, but most notably as part of our deploy and manual testing processes). For my local development purposes, I have no need to stay up-to-date on most of these extraneous references. Before adopting magit, when using git porcelain I'd generally use specific pull and fetch commands, both to save time and to leave my repo un-cluttered. Whenever I wanted to update master, for instance, I'd usually use

git checkout master
git pull origin master
git checkout -

When I adopted magit, I was initially puzzled by how long pulling (using magit-pull-from-upstream) would take. As time went on I eventually discovered (using the magit-process buffer) that magit was using the command git pull origin to update my master branch. That command, in addition to updating master, fetches every remote branch under the sun (which is lot of pointless references I don't need, remember).

I've solved this issue for myself (i.e. I'm not looking for a solution here) by switching to using magit-pull-from-pushremote instead, after configuring the push-to remote. That, evidently, uses git pull origin master (as I expected I'd get from the other command).

I'm looking for an explanation for the different behavior of these two commands. Why would one yield git pull origin and one yield git pull origin master? Why wouldn't both do the (in my opinion objectively more useful) git pull origin master?

  • 1
    "Why wouldn't both do the (in my opinion objectively more useful) git pull origin master?" - Of course if it was this way someone would ask "where is the objectively more useful git pull origin command, why do I have to pull each branch individually?" – npostavs Jun 29 '16 at 10:35
  • I sometimes have lots of branches which I don't want to keep up to date. I just pulled them once, had a look and forgot about them. So I don't want to pull the latest changes from all these. I'm only interested in maste. I like a lot that I have control. I can choose to update one or multiple branches, depending on my needs. – caisah Jun 29 '16 at 16:14
  • @npostavs I know that I expressed an opinion, and that others may feel otherwise. I don't need you to tell me that that aspect of my question isn't completely objective. Ultimately the reason I asked the question is because magit-pull-from-upstream is the more natural first choice, so in a sense its behavior is more relevant. There doesn't appear to be a way to configure that function to use my command, which seems backwards to me. Additionally, I tried to provide context as to why I don't want to fetch branches I don't explicitly list. I understand that's not everyone's situation. – matthugs Jun 30 '16 at 18:23
  • Well I think only tarsius can answer the question definitively because he wrote the code, but he's on vacation till August. Perhaps it was just simple oversight; I see that both magit-fetch-from-{upstream,pushremote} do git fetch <remote> without giving a branch. – npostavs Jun 30 '16 at 19:42
  • @caisah Another way to restrict which branches are pulled is to configure remote.origin.fetch. – npostavs Jun 30 '16 at 19:42
1

magit-pull-from-upstream does not explicitly specify the remote branch because if we did that, then tags that point to commits that are being pulled would not pulled along with the branch (i.e. the commits and the branch ref).

For a while (2.? to 2.6.2) the remote branch was explicitly specified for safety reasons, but I went back to not specifying the remote branch after a user pointed out the above issue.

magit-pull-from-pushremote does specify the remote branch because in that case it has to be specified or it might pull from branch.NAME.merge (i.e. the upstream) instead of the branch "with the same name as the local branch".


To limit what branches are being pulled by git's dwim pull command (git pull or git pull REMOTE) and by extension magit-pull-from-upstream, configure remote.NAME.fetch.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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