Related
After a fresh Linux install I'm trying to set up my environment and I keep getting the Git: gpg failed to sign the data error upon committing changes locally. I'm using Visual Studio Code, proprietary, not opensource version.
.gitconfig:
[user]
name = djweaver-dev
email = djweaver#djweaver.dev
signingkey = 37A0xxxx...
[core]
excludesfile = /home/dweaver/.gitignore_global
[commit]
gpgSign = true
yikes. furthermore I can't find a way to copy the output log nor can I find where that log is so here is a pic:
Steps I have taken so far:
generated new key (RSA 4096) in gnugp
added signing key to global .gitconfig
set "git.enableCommitSigning": true in Visual Studio Code settings
cloned my repo from github
Typically when I commits in the past I would get a dialog box requesting GPG authentication upon commit. I do not get this now, just the error dialog.
UPDATE: Okay now I'm really confused. I restarted vscode (not the first time I've done this in this process) and voilà, it works. Only thing I can think of is maybe I biffed the directory somehow? Either way, it works now.
UPDATE: Oddly, I'm back to this same issue almost a month later after a fresh arch install. I've tried everything that I've been able to find on this site, and nothing works.
I've tried adding export GPG_TTY=$(tty) to .bash_profile, and also .bashrc
Git log:
Looking for git in: git
Using git 2.26.2 from git
> git rev-parse --show-toplevel
> git rev-parse --git-dir
Open repository: /home/dw/dev/website
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse master
> git rev-parse --symbolic-full-name master#{u}
> git rev-list --left-right master...refs/remotes/origin/master
> git for-each-ref --format %(refname) %(objectname) --sort -committerdate
> git remote --verbose
Failed to watch ref '/home/dw/dev/website/.git/refs/remotes/origin/master', is most likely packed.
Error: ENOENT: no such file or directory, watch '/home/dw/dev/website/.git/refs/remotes/origin/master'
at FSWatcher.start (internal/fs/watchers.js:165:26)
at Object.watch (fs.js:1270:11)
at Object.t.watch (/usr/lib/code/extensions/git/dist/main.js:1:604919)
at T.updateTransientWatchers (/usr/lib/code/extensions/git/dist/main.js:1:83965)
at e.fire (/usr/lib/code/out/vs/workbench/services/extensions/node/extensionHostProcess.js:46:87)
at e.updateModelState (/usr/lib/code/extensions/git/dist/main.js:1:103179)
> git config --get commit.template
> git check-ignore -v -z --stdin
> git check-ignore -v -z --stdin
> git commit --quiet --allow-empty-message --file - -S
error: gpg failed to sign the data
fatal: failed to write commit object
> git config --get-all user.name
> git config --get-all user.email
Same config as last time, user.name and user.email both match each key I've been trying it with... user.signingkey matches. Not sure where else to go with this one, as I've tried it across newly initialized local repos as well as repos that I've pulled from github both with official MS vscode (AUR) and OSS version, in the vscode terminal emulator as well as gnome terminal with same results so it has to be either a git thing or a gnugp thing.
What I have noticed is that after committing without signing, it will work immediately after: I get prompted for my key passphrase the first time, then it works on subsequent commits until a seemingly random number of minutes later, it just doesn't work anymore and the process has to be repeated.
There were a few macos users posting about having a stalled gpg-agent running in the background and it fixed it for them, however, I am seeing:
[dw#dwLinux website]$ gpg-agent
gpg-agent[2870]: gpg-agent running and available
Whats interesting also is that by doing echo "test" | gpg --clearsign I get the same results: it works for a short period of time, then I can't sign anymore.
UPDATE
Okay so day number 2 of trying to fix this. To rule out the gpg-agent theory as described here I followed the instructions on how to reload gpg-agent using the $ gpg-connect-agent reloadagent /bye command demonstrated on the Arch Linux Wiki
This had no effect
So being that I can reproduce this problem across vscode official, oss code, and vscodium, as well as bash, I thought maybe this was a permissions related issue, as so many problems with linux typically are. I added my user to all kinds of groups, including root, and this also had no effect so I think I can safely rule out the following:
VS Code
GnuGP
gpg-agent
Linux permissions
So my next focus was the config files themselves, but as has been stated before the credentials match the key in .gitconfig and my .bash_profile has been correctly configured with export GPG_TTY=$(tty).
An interesting note on this from the official GnuPG docs shows a syntax discrepency between their way, and the way you are instructed to append this to .bash_profile on the GitHub docs here
From GnuPG: "The far most common reason for this is that the environment variable GPG_TTY has not been set correctly. Make sure that it has been set to a real tty device and not just to ‘/dev/tty’; i.e. ‘GPG_TTY=tty’ is plainly wrong; what you want is ‘GPG_TTY=tty’ — note the back ticks. Also make sure that this environment variable gets exported, that is you should follow up the setting with an ‘export GPG_TTY’"
As I understood $(whatever) in bash was to execute a command, but for safe measure I've appended .bash_profile using both ways and neither solved the issue.
One last thing
In this post the user talks about gpg-agent authentication not being available when daemonized and gpg access is being initiated by another application (such as an IDE like VSCode), which explains how I could temporarily sign commits after committing a random file or doing echo "test" | gpg --clearsign and being authenticated... but alas like most other 'solutions' to this topic, they reveal that all they had to do in the end was add export GPG_TTY=$(tty) to their .bash_profile, which I have already tried.
Where to go from here?
I still can't explain why it worked on my previous install, and frankly, not a whole lot has changed afaik. I typically do fresh installs often and keep a pretty minimal arch linux build with lts kernel each time w/base-devel and nodejs/python/git/vscode/firefox/discord is pretty much my entire workflow. I'm all out of ideas.
first make sure to add
export GPG_TTY=$(tty)
in your .bashrc
Apparently VSCode doesn't ask for the passphrase and that's why it gives an error.
I don't know the reason.
My personal solution do a console commit first or run the following line
echo "test" | gpg --clearsign
Edit
In order to avoid typing the passphrase on every commit, you can make GPG remember it for 8 hours or until the next reboot:
mkdir -p ~/.gnupg
echo "default-cache-ttl 28800" >> ~/.gnupg/gpg-agent.conf
GitHub Guide
Maybe git cannot find gpg? That was my problem with working with VSCode and using Remote-Containers to create development containers. Try running this in the Terminal within VSCode (in the container)
git config --global --unset gpg.program
git config --global --add gpg.program /usr/bin/gpg
or wherever your gpg is located. You can find out by typing
which gpg
If that works then you can put it in your Dockerfile for your development container.
I had the same issue a few days ago while using VS Code with WSL. The problem is that VS Code doesn't load the .profile file (and all the environment variables in it) correctly (try to run this command but it doesn't get the correct result: echo $GPG_TTY). Fortunately, setting the "-l" option for shell args in VS Code preferences worked for me. This ensures that the .profile (or .zprofile) file is successfully loaded.
I added these lines to settings.json:
"terminal.integrated.shellArgs.linux": [
"-l"
]
Make sure to add export GPG_TTY=$(tty) in your .profile file and restart your terminal and VS Code.
Update: Since VSCode is deprecating the shellArgs oprion, use
the following snippet as an alternative.
"terminal.integrated.profiles.linux": {
"bash": {
"path": "bash",
"args": ["-l"],
"icon": "terminal-bash"
},
"zsh": {
"path": "zsh",
"args": ["-l"],
},
"fish": {
"path": "fish",
"args": ["-l"],
},
"tmux": {
"path": "tmux",
"args": ["-l"],
"icon": "terminal-tmux"
},
"pwsh": {
"path": "pwsh",
"args": ["-l"],
"icon": "terminal-powershell"
}
},
"terminal.integrated.defaultProfile.linux": "bash"
-l option is added to all terminal profiles above,
delete unused profiles and set your default profile at your wish.
I have same issue, and I have resolved it.
Background
macOS
GPG Suite to generate GPG key
pinentry-mac
How I solve this problem
I saw this answer, and followed it.
Get keys
gpg2 --list-keys
Result
/Users/xxuser/.gnupg/pubring.kbx
---------------------------------
pub dsa2048 2010-08-19 [SC] [expires: 2024-05-11]
85E38F69046BSDFB07B76D78F0500D026C4
uid [ unknown] GPGTools Team <team#gpgtools.org>
uid [ unknown] [jpeg image of size 6329]
sub rsa4096 2014-04-08 [S] [expires: 2024-05-11]
sub rsa4096 2020-05-11 [E] [expires: 2024-05-11]
pub rsa4096 2020-05-04 [SC] [expires: 2024-05-03]
B97E9964ACAD1928300D37CC8A9E3745558E41AF
uid [ unknown] GPGTools Support <support#gpgtools.org>
sub rsa4096 2020-05-04 [E] [expires: 2024-05-03]
pub rsa4096 2021-07-29 [SC] [expires: 2025-07-29]
926E268C01892E8A2FCCD2A101CEB6267272A9A5
uid [ultimate] xxuser <x#xxgolo.com>
sub rsa4096 2021-07-29 [E] [expires: 2025-07-29]
Since x#xxgolo.com is the email that I create secret for, 926E268C01892E8A2FCCD2A101CEB6267272A9A5 is the key code I need.
Let git user this key.
git config --global user.signingkey 926E268C01892E8A2FCCD2A101CEB6267272A9A5
Now it should work.
git commit -S -m "This is a signed commit"
note If you need it to work with Github, you need to add your public GPG key to Github, following this Guide.
Make sure echo "test" | gpg --clearsign runs successfully first before trying the below.
Very helpful to check what git commit is doing under the hood. Run the following commit with GIT_TRACE=1 as follow
GIT_TRACE=1 git commit -S -m "MESSAGE"
This will show what user name, email and key does git uses when committing.
In my case, I found that git was picking up the wrong user's and key details for signing the commit. I mainly intended to use the local config of the repo rather than the global and adding the following to the local git config (located at "REPO_PATH/.git/config") got signing the commit to work both in Terminal and VSCode
[user]
name = USER NAME
email = USER EMAIL
signingKey = SIGNING KEY
It can also be set with the following:
git config --local user.name "USER NAME"
git config --local user.email "USER EMAIL"
git config --local user.signingkey "USIGNING KEY"
I'm not sure if this is too late, but... I did find an immediate solution.
To see what user.name and user.email you have, run:
git config -l
You may notice two entries for user.name. You may have made the same mistake as me! I put my actual name in there instead of GitHub username, and there ended up being two entries of user.name! I just changed the global user.name back to my github username, like so...
git config --global user.name "ghusername"
Next, git commit, and it should work:
git commit -m "<YOUR MESSAGE>"
Let me know if this works for you, I want to know if it's the same problem.
We are working on integrating GitLab (enterprise edition) in our tooling, but one thing that is still on our wishlist is to create a merge request in GitLab via a command line (or batchfile or similar, for that matter). We would like to integrate this in our tooling. Searching here and on the web lead me to believe that this is not possible with native GitLab, but that we need additional tooling for that.
Am I correct? And what kind of tooling would I want to use for this?
As of GitLab 11.10, if you're using git 2.10 or newer, you can automatically create a merge request from the command line like this:
git push -o merge_request.create
More information can be found in the docs.
It's not natively supported, but it's not hard to throw together. The gitlab API has support for opening MR: https://github.com/gitlabhq/gitlabhq/blob/master/doc/api/merge_requests.md#create-mr
You can use following utility.
Disclosure : I developed it.
https://github.com/vishwanatharondekar/gitlab-cli
You can create merge request using this.
Some of the features it has are.
Base branch is optional. If base branch is not provided. Current branch is used as base branch.
target branch is optional. If target branch is not provided, default branch of the repo in gitlab will be used.
Created pull request page will be opened automatically after successful creation.
If title is not supported with -m option value. It will be taken from in place editor opened. First line is taken as title.
In the editor opened third line onwards takes as description.
Comma separated list of labels can be provided with its option.
Supports CI.
Repository specific configs can be given.
squash option is available.
remove source branch option is available.
If you push your branch before this command (git push -o merge_request.create) it will not work. Git will response with Everything up-to-date and merge request will not be created (gitlab 12.3).
When I tried to remove my branch from a server (do not remove your local branch!!!) then it worked for me in this form.
git push --set-upstream origin your-branch-name -o merge_request.create
In addition to answering of #AhmadSherif, You can use merge_request.target=<branch_name> for declaring the target branch.
sample usage:
git push -o merge_request.create -o merge_request.target=develop origin feature
Simple This:
According to the Gitlab documents, you can define an alias for this command to simpler usage.
git config --global alias.mwps "push -o merge_request.create -o
merge_request.target=master -o merge_request.merge_when_pipeline_succeeds"
I made a shell function which opens up the GitLab MR web page with desired parameters.
Based on the directory with the git repo you are currently in, it:
Finds the correct URL to your repo.
Sets the source branch to the branch you're currently on.
As a optional first argument you can provide the target branch. Otherwise, GitLab defaults to your default branch, which is typically master.
gmr() {
# A quick way to open a GitLab merge request URL for the current git branch
# you're on. The optional first argument is the target branch.
repo_path=$(git remote get-url origin --push | sed 's/^.*://g' | sed 's/.git$//g')
current_branch=$(git rev-parse --abbrev-ref HEAD)
if [[ -n $1 ]]; then
target_branch="&merge_request[target_branch]=$1"
else
target_branch=""
fi
xdg-open "https://gitlab.com/$repo_path/merge_requests/new?merge_request[source_branch]=$current_branch$target_branch"
}
You can set more default values in the URL, like removing the source branch after merge:
&merge_request[force_remove_source_branch]=true
Or assignee to someone:
&merge_request[assignee_ids][]=12345
Or add a reviewer:
&merge_request[reviewer_ids][]=54321
You can easily find the possible query string parameters by searching the source of the GitLab MR webpage for merge_request[.
As of now, GitLab sadly does not support this, however I recently saw it on their issue tracker. It appears one can expect a 'native tool' in the upcoming months.
GitLab tweeted out about numa08/git-gitlab some time ago, so I guess this would be worth a try.
In our build script we just pop up the browser with the correct URL and let the developer write his comments in the form hit save to create the merge request. You get this url with the correct parameters by creating a merge request manually and copying the url of the form.
#!/bin/bash
set -e
set -o pipefail
BRANCH=${2}
....
git push -f origin-gitlab $BRANCH
open "https://gitlab.com/**username**/**project-name**/merge_requests/new?merge_request%5Bsource_branch%5D=$BRANCH&merge_request%5Bsource_project_id%5D=99999&merge_request%5Btarget_branch%5D=master&merge_request%5Btarget_project_id%5D=99999"
You can write a local git alias to open a Gitlab Merge Request creation page in the default browser for the currently checked-out branch.
[alias]
lab = "!start https://gitlab.com/path/to/repo/-/merge_requests/new?merge_request%5Bsource_branch%5D=\"$(git rev-parse --abbrev-ref HEAD)\""
(this is a very simple alias for windows; I guess there are equivalent replacements for "start" on linux and fancier aliases that work with github and bitbucket too)
As well as being able to immediately see&modify the details of the MR, the advantage of this over using the merge_request.create push option is that you don't need your local branch to be behind the remote for it to work.
You might additionally want to store the alias in the repo itself.
I use https://github.com/mdsb100/cli-gitlab
I am creating the MR from inside of a gitlab CI docker container based on alpine linux, so I include the install command in before-script (that could also be included in your image). All commands in the following .gitlab-ci.yml file, are also relevant for normal command line usage (as long as you have the cli-gitlab npm installed).
variables:
TARGET_BRANCH: 'live'
GITLAB_URL: 'https://your.gitlab.net'
GITLAB_TOKEN: $PRIVATE_TOKEN #created in user profile & added in project settings
before-script:
-apk update && apk add nodejs && npm install cli-gitlab -g
script:
- gitlab url $GITLAB_URL && gitlab token $GITLAB_TOKEN
- 'echo "gitlab addMergeRequest $CI_PROJECT_ID $CI_COMMIT_REF_NAME \"$TARGET_BRANCH\" 13 `date +%Y%m%d%H%M%S`"'
- 'gitlab addMergeRequest $CI_PROJECT_ID $CI_COMMIT_REF_NAME "$TARGET_BRANCH" 13 `date +%Y%m%d%H%M%S` 2> ./mr.json'
- cat ./mr.json
This will echo true if the merge request already exists, and echo the json result of the new MR if it succeeds to create one (also saving to a mr.json file).
Since GitLab 15.7 (Dec. 2022), the GitLab CLI glab is officially integrated to GitLab.
Introducing the GitLab CLI
The command line is one of the most important tools in a software engineer’s toolkit and the majority of their process and work revolve around tools available there. They customize their CLI with styles and extend it through applications to ensure maximum efficiency while performing tasks. The CLI is the backbone of scripts and workflows developers depend on to complete their work.
To support more developers where they’re already working, we’ve adopted the open source project glab, which will form the foundation of GitLab’s native CLI experience.
The GitLab CLI brings GitLab together with Git and your code, with no application or tab switching required.
You can read about our adoption of glab, our partnership with 1Password, and how to contribute to the project in our blog post.
A special thank you to Clement Sam for creating glab and trusting us with its future.
That means you can create a MR with glab mr create:
glab mr create -a username -t "fix annoying bug"
I have a this to aliases in my .gitconfig file:
setmeld = config --global diff.external git-meld
nomeld = config --global --unset diff.external
That way I can set and unset the visual diff tool meld.
When I issue:
git setmeld
...the following is added to my .gitconfig file:
[diff]
external = git-meld
When I issue:
git setmeld
...the external = git-meld setting is deleted from my .gitconfig file, but the [diff] section header stays.
If I later run git setmeld again my .gitconfig ends up having two [diff] section headers:
[diff]
[diff]
external = git-meld
If I unset and then set again the external git-meld diff tool I end up with this:
[diff]
[diff]
[diff]
external = git-meld
The problem is not because of the aliases. The same happens if I issue the commands by themselves git config --global diff.external git-meld and config --global --unset diff.external.
- Can I avoid that weird behavior?
OS: Ubuntu 12.04.5 LTS
git version: 1.7.9.5
git doesn't like empty sections.
Use the command
git config diff.dummy "dummy line"
You can edit the config to remove the extra [diff] lines, but be careful to save the config file to config.save first. If git finds that the config file is corrupted, it will refuse further commands.
Then set unset cycles will not add more duplicate sections
Your Git is very old (the current version is 2.8+) and you probably should update yours. The bug may be fixed in newer versions (I have not checked).
Meanwhile, though, this seems like a harmless bug: Git is leaving the section header in place even though the entire section is empty, then adding another section header even though there is already an existing section header. Given the way Git scans the file, though, you may repeat a section header (and a setting) as often as you like. For settings that are not cumulative,1 the last setting overrides the earlier ones.
As a rather hacky workaround, you can just set something else so that the section never becomes entirely empty. Any value will do: anything that Git never uses will just sit around unused, keeping the section not-empty.
There is in fact another diff setting you might want to set, though: diff.renameLimit sets the default size of the rename-detection queue for most git diff operations. In some versions, the "default default" is 500, 1000, and 2000 (it has been growing over time). As of the latest upcoming Git, the new default is 0, which means "unlimited" (which really means "use internal maximum"). I have kept mine set to 0 since very early days.
1One example of a cumulative setting is the value(s) for remote.origin.fetch, assuming you have a [remote "origin"] section. Each fetch = ... value in this section is accumulated, and when running git fetch origin, Git runs each reference obtained from that remote through all the mappings to find its local name. If the mapping produces multiple names, Git complains of an error. (Usually there is only one setting anyway, so that there is only one possible output.)
When I run
sudo puppet agent -t
after a long phase of catalog loading, I get a message:
info: Applying configuration version '1403590182'
What is that number 1403590182 referring to?
In fact I have noticed that if I run twice in a row sudo puppet agent -t, I get different configuration version numbers even if the modules have not changed!
How can I determine which version of each module is being applied to the node?
from the documentation config_version
How to determine the configuration version. By default, it will be the
time that the configuration is parsed, but you can provide a shell
script to override how the version is determined. The output of this
script will be added to every log message in the reports, allowing you
to correlate changes on your hosts to the source version on the
server.
Setting a global value for config_version in puppet.conf is not
allowed (but it can be overridden from the commandline). Please set a
per-environment value in environment.conf instead. For more info, see
https://puppet.com/docs/puppet/latest/environments_about.html
The time is represented as a unix time stamp as such yours indicates "06/24/2014 # 6:09am" (and i just realised how old this Q was)
If the manifests are git controlled the administrator can let the Puppet master know how to describe the version with the statement below in /etc/puppet/puppet.conf (on the Puppet master). One such statement goes in each environment section with the path adjusted to where the environment looks for manifests.
config_version = git --git-dir $confdir/modules/production/.git describe --all --long
If you use some other version control system i'm sure there's some equivalent command to get an indication of the revision.
I'm on a fresh install of Linux Mint.
I'm getting the following error when trying to push from any repository:
error: Malformed value for push.default: simple
error: Must be one of nothing, matching, tracking or current.
fatal: bad config file line 8 in /home/leng/.gitconfig
fatal: Could not read from remote repository.
This is very odd, because I definitely have a version that supports the simple push behavior.
The output of git --version is git version 1.8.3.2.
The contents of ~/.gitconfig:
[user]
name = My Name
email = MyEmail#website.com
[color]
ui = true
[push]
default = simple
Here's where it gets creepy.
If I change the behavior to matching (or to nothing, tracking, or current, for that matter), then attempt to push, I get the same exact error message. How is that possible? Is it caching the config somehow? I've even tried rebooting. I've even tried purging GIT completely from the system (and deleting ~/.gitconfig) then reinstalling it.
If I delete the [push] section completely from the .gitconfig file (or if I delete the file entirely), then try to push, then I get this:
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:
git config --global push.default matching
To squelch this message and adopt the new behavior now, use:
git config --global push.default simple
See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
'current' instead of 'simple' if you sometimes use older versions of Git)
error: Malformed value for push.default: simple
error: Must be one of nothing, matching, tracking or current.
fatal: bad config file line 8 in /home/leng/.gitconfig
fatal: Could not read from remote repository.
...so it appears to be both acknowledging that I haven't chosen a pushing behavior, but then also saying that I've chosen an unsupported behavior. What on earth is going on here?
I even get the error if I delete ~/.gitconfig completely.
Can anyone help me out with this witchcraft?
Thanks!
EDIT:
Here is a .git/config file requested:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = ssh://{my remote repo}
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
Okay, so I fixed it, but the method is absolute witchcraft.
I tried to isolate the problem by purging GIT, deleting the config file, reinstalling GIT, then creating a local bare repository, then cloning it, then attempting to push from there. Pretty much like this:
sudo apt-get purge git-core
rm -f ~/.gitconfig
sudo apt-get install git-core
cd /git
mkdir foo
cd foo
git init --bare
cd /var/www
git clone /git/foo
cd foo
touch blah.txt
git add -A
git config --global user.name "Name"
git config --global user.email "user#email.com"
git commit -m "Blah"
git push
...same exact error message, no change there. (Still some serious witchcraft.)
Then, I deleted one of my repositories that doesn't have a local origin (it connects to its origin via SSH) and cloned the repository anew after deleting it (with a fresh git clone ssh://... command).
I got an error from the clone command:
remote: Malformed value for push.default: simple
remote: Must be one of nothing, matching, tracking or current.
Ah ha! Now it says remote instead of error. So the remote doesn't support this behavior. (That doesn't explain why the error persists on local-only repositories with local origins, then, though.)
So I then SSH'ed into the remote server and updated the git-core there to the latest version, re-attempted to clone the repository from my local machine, and it worked.
Now, I can finally git push. Insanely, this also fixed it so I can git push from the entirely local /var/www/foo to the also entirely local /git/foo (the local origin bare repository). SSH'ing into this remote server and updating it somehow - WITCHCRAFT - fixed my local machine's error.
Why on earth the entirely local repos care about an entirely different machine's GIT version is... beyond me. How utterly, utterly insane.
I had the same error message on git push.
For me it turned out that the remote user's git was an older version (1.7.2.5),
and I had recently updated the remote ~/.gitconfig to include:
[push]
default = simple
The solution was to remove this setting from the remote's configuration.
Since it seems other people are having this issue, and I found a solution HERE, I thought I'd post the solution that worked for me.
IN SHORT:
The solution I found was at this page. Evidently the best solution is to upgrade to a newer version of Git (if possible). That was not an option for me, however. From a local machine, I typed the following command:
git config -–global push.default upstream
This got rid of the Malformed value for push.default: simple error I had been getting. I'm not entirely sure what upstream does, however.
MY CONTEXT (for comparison): I had an empty (bare) repository on a remote computer, and I had a few repositories on a couple "local" workstations. I pull from the remote repository, do some work, and then push my work to the remote repository. Pushing/pulling was accomplished via SSH. Most of the time, while working on a local machine, pushing/pulling would result in the error described above.
In short, before the fix, I had the following ~/.gitconfig file on the remote machine:
[user]
name = Foo Bar
email = FooBarPerson#email.com
[diff]
external = /Users/foobar/bin/git-diff-cmd.sh
[color]
diff = auto
status = auto
branch = auto
[push]
default = simple
After entering in the above command, my ~/.gitconfig file on the remote machine changed to:
[user]
name = Foo Bar
email = FooBarPerson#email.com
[diff]
external = /Users/foobar/bin/git-diff-cmd.sh
[color]
diff = auto
status = auto
branch = auto
[push]
default = upstream
Version information:
Remote machine (repository location): 1.9.4
My laptop: 1.8.5.2 (Apple Git-48)
Other computer I work on: 1.7.7.4
Here's another site that may be useful to some people:
http://www.lorrin.org/blog/2011/10/03/argumentless-git-pull-and-git-push/comment-page-1/