1

When I call git remote show <remote_name> I see below

  Local branches configured for 'git pull':
    master           merges with remote master
  Local refs configured for 'git push':
    master           pushes to master           (up to date)

How can I exclude configured pushes? so git push from master branch will throw error and only push will be with explicit remote name git push <remote_name> <remote_branch_name>

logcat
  • 3,435
  • 1
  • 29
  • 44

3 Answers3

2

If you change your gitconfig of push.default to nothing then you will need to specify <remote_name> and <remote_branch_name> every time on all branches.

git config --global push.default nothing (remove --global for project specific config)

After setting this you should get an error similar to the following when you git push.

fatal: You didn't specify any refspecs to push, and push.default is "nothing".

Update:

If you just want to disable automatic pushing for a specific branch I would just remove the tracking config.

One way is to edit your project's .git/config and delete the [branch="branchname"] config.

Or programmatically: git config --unset branch.branchname.remote which removes the remote=remotename part of the branch's config.

lebreeze
  • 5,094
  • 26
  • 34
  • can I do that for only one particular remote (or even remote branch?) – logcat Apr 07 '13 at 10:55
  • I would just remove the tracking branch information for that branch so it won't know where to push to. Then you would always need to say `git push origin master` (Remove [branch="master"] from project's .git/config) – lebreeze Apr 07 '13 at 11:01
  • When I delete remote tracking branch like here http://stackoverflow.com/a/3046478/289686, git push still pushes. But removing [branch] from config helps. I can't push by default, but can with explicit repo & branch names. Thanks for help. – logcat Apr 07 '13 at 11:07
  • you can modify answer, I'll award bounty tomorrow :) – logcat Apr 07 '13 at 11:09
  • Won't that also prevent `git pull` from working correctly too? And `@{u}` is also no longer useful. – John Szakmeister Apr 07 '13 at 12:09
  • not working git pull for master branch is acceptable evil. Push default nothing will force me to type remote/branch for every other push, and i am lazy :) – logcat Apr 07 '13 at 12:41
  • and it is enough to delete just "remote=remotename" from config. Also "git remote show " no matter what keep saying that master is configured to push. – logcat Apr 07 '13 at 17:10
  • What about `git config --add remote..push ""` to just make the push refspec for a specific branch invalid? – kostix Apr 08 '13 at 10:01
  • @kostix it's the same as above but for whole repo. and I was confused with "git remote show " keep saying that master pushes to master, when it's not. – logcat Apr 08 '13 at 15:29
1

Make sure that you don't have a push config for your remote configured:

git config --unset remote.<remote_name>.push

Configure push.default to nothing:

git config push.default nothing

Unfortunately, it appears that git remote show <remote_name> doesn't appear to take account of the config.push setting (it always assumes 'matching') so Local refs configured for 'git push' will still be listed in the output.

CB Bailey
  • 755,051
  • 104
  • 632
  • 656
1

It's not entirely clear what you want, but if you want to disable a bare git push all together, you can do:

git config --local push.default nothing

This means that the bare git push will assume no default refspec, and you must specify it. The only other thing I can think to do is create an alias, and use that for pushing. So, something like this in your .gitconfig:

[aliases]
p = "!_() { cur=$(git symbolic-ref HEAD); if test \"$cur\" = refs/heads/master -a -z \"$1\"; then { echo \"please specify push target\"; exit 1; } ; fi; git push \"$@\" ; }; _"

Then git p would reject pushing when no other command line parameters are specified on the command line when on master. Otherwise, it'd use the push default.

I believe that's all the flexibility that you can achieve from git right now. If you need something more, perhaps talking about it on the git list may convince someone to implement a feature for you. You'll need a compelling use-case though.

John Szakmeister
  • 44,691
  • 9
  • 89
  • 79