summaryrefslogtreecommitdiff
path: root/git-p4.py
AgeCommit message (Collapse)AuthorFilesLines
2015-12-15Merge branch 'ls/p4-keep-empty-commits' into maintLibravatar Junio C Hamano1-17/+27
"git p4" used to import Perforce CLs that touch only paths outside the client spec as empty commits. It has been corrected to ignore them instead, with a new configuration git-p4.keepEmptyCommits as a backward compatibility knob. * ls/p4-keep-empty-commits: git-p4: add option to keep empty commits
2015-12-10git-p4: add option to keep empty commitsLibravatar Lars Schneider1-17/+27
A changelist that contains only excluded files due to a client spec was imported as an empty commit. Fix that issue by ignoring these commits. Add option "git-p4.keepEmptyCommits" to make the previous behavior available. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Helped-by: Pete Harlan Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-01Merge branch 'eg/p4-submit-catch-failure' into maintLibravatar Jeff King1-34/+37
Just like the working tree is cleaned up when the user cancelled submission in P4Submit.applyCommit(), clean up the mess if "p4 submit" fails. * eg/p4-submit-catch-failure: git-p4: clean up after p4 submit failure
2015-12-01Merge branch 'ld/p4-detached-head' into maintLibravatar Jeff King1-9/+20
Make git-p4 work on a detached head. * ld/p4-detached-head: git-p4: work with a detached head git-p4: add option to system() to return subshell status git-p4: add failing test for submit from detached head
2015-11-24git-p4: clean up after p4 submit failureLibravatar GIRARD Etienne1-34/+37
When "p4 submit" command fails in P4Submit.applyCommit, the workspace is left with the changes. We already have code to revert the changes to the workspace when the user decides to cancel submission by aborting the editor that edits the change description, and we should treat the "p4 submit" failure the same way. Clean the workspace if p4_write_pipe raised SystemExit, so that the user don't have to do it themselves. Signed-off-by: GIRARD Etienne <egirard@murex.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Jeff King <peff@peff.net>
2015-11-24git-p4: work with a detached headLibravatar Luke Diamand1-7/+16
When submitting, git-p4 finds the current branch in order to know if it is allowed to submit (configuration "git-p4.allowSubmit"). On a detached head, detecting the branch would fail, and git-p4 would report a cryptic error. This change teaches git-p4 to recognise a detached head and submit successfully. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Jeff King <peff@peff.net>
2015-11-24git-p4: add option to system() to return subshell statusLibravatar Luke Diamand1-2/+4
Add an optional parameter ignore_error to the git-p4 system() function. If used, it will return the subshell exit status rather than throwing an exception. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Jeff King <peff@peff.net>
2015-11-03Merge branch 'ls/p4-translation-failure' into maintLibravatar Junio C Hamano1-11/+16
Work around "git p4" failing when the P4 depot records the contents in UTF-16 without UTF-16 BOM. * ls/p4-translation-failure: git-p4: handle "Translation of file content failed" git-p4: add test case for "Translation of file content failed" error
2015-11-03Merge branch 'ld/p4-import-labels' into maintLibravatar Junio C Hamano1-8/+17
Correct "git p4 --detect-labels" so that it does not fail to create a tag that points at a commit that is also being imported. * ld/p4-import-labels: git-p4: fix P4 label import for unprocessed commits git-p4: do not terminate creating tag for unknown commit git-p4: failing test for ignoring invalid p4 labels
2015-09-22git-p4: handle "Translation of file content failed"Libravatar Lars Schneider1-11/+16
A P4 repository can get into a state where it contains a file with type UTF-16 that does not contain a valid UTF-16 BOM. If git-p4 attempts to retrieve the file then the process crashes with a "Translation of file content failed" error. More info here: http://answers.perforce.com/articles/KB/3117 Fix this by detecting this error and retrieving the file as binary instead. The result in Git is the same. Known issue: This works only if git-p4 is executed in verbose mode. In normal mode no exceptions are thrown and git-p4 just exits. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-28git-p4: fix P4 label import for unprocessed commitsLibravatar Luke Diamand1-8/+17
With --detect-labels enabled, git-p4 will try to create tags using git fast-import by writing a "tag" clause to the fast-import stream. If the commit that the tag references has not yet actually been processed by fast-import, then the tag can't be created and git-p4 fails to import the P4 label. Teach git-p4 to use fast-import "marks" when creating tags which reference commits created during the current run of the program. Commits created before the current run are still referenced in the old way using a normal git commit. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-28git-p4: do not terminate creating tag for unknown commitLibravatar Luke Diamand1-2/+2
If p4 reports a tag for a commit that git-p4 does not know about (e.g. because it references a P4 changelist that was imported prior to the point at which the repo was cloned into git), make sure that the error is correctly caught and handled. rather than just crashing. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-28git-p4: honor core.ignorecase when using P4 client specsLibravatar Lars Schneider1-0/+7
Perforce depot may record paths in mixed cases, e.g. "p4 files" may show that there are these two paths: //depot/Path/to/file1 //depot/pATH/to/file2 and with "p4" or "p4v", these end up in the same directory, e.g. //depot/Path/to/file1 //depot/Path/to/file2 which is the desired outcome on case insensitive systems. If git-p4 is used with client spec "//depot/Path/...", however, then all files not matching the case in the client spec are ignored (in the example above "//depot/pATH/to/file2"). Fix this by using the path case that appears first in lexicographical order when core.ignorecase is set to true. This behavior is consistent with "p4" and "p4v". Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-24Merge branch 'ld/p4-changes-block-size'Libravatar Junio C Hamano1-22/+63
More Perforce row number limit workaround for "git p4". * ld/p4-changes-block-size: git-p4: fixing --changes-block-size handling git-p4: add tests for non-numeric revision range git-p4: test with limited p4 server results git-p4: additional testing of --changes-block-size
2015-06-11Merge branch 'mt/p4-depotFile-at-version'Libravatar Junio C Hamano1-1/+1
* mt/p4-depotFile-at-version: p4: retrieve the right revision of the file in UTF-16 codepath
2015-06-10git-p4: fixing --changes-block-size handlingLibravatar Luke Diamand1-22/+63
The --changes-block-size handling was intended to help when a user has a limited "maxscanrows" (see "p4 group"). It used "p4 changes -m $maxchanges" to limit the number of results. Unfortunately, it turns out that the "maxscanrows" and "maxresults" limits are actually applied *before* the "-m maxchanges" parameter is considered (experimentally). Fix the block-size handling so that it gets blocks of changes limited by revision number ($Start..$Start+$N, etc). This limits the number of results early enough that both sets of tests pass. Note that many other Perforce operations can fail for the same reason (p4 print, p4 files, etc) and it's probably not possible to workaround this. In the real world, this is probably not usually a problem. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-05Merge branch 'ld/p4-editor-multi-words'Libravatar Junio C Hamano1-1/+1
Unlike "$EDITOR" and "$GIT_EDITOR" that can hold the path to the command and initial options (e.g. "/path/to/emacs -nw"), 'git p4' did not let the shell interpolate the contents of the environment variable that name the editor "$P4EDITOR" (and "$EDITOR", too). Make it in line with the rest of Git, as well as with Perforce. * ld/p4-editor-multi-words: git-p4: tests: use test-chmtime in place of touch git-p4: fix handling of multi-word P4EDITOR git-p4: add failing test for P4EDITOR handling
2015-05-27p4: retrieve the right revision of the file in UTF-16 codepathLibravatar Miguel Torroja1-1/+1
Fixing bug with UTF-16 files when they are retrieved by git-p4. It was always getting the tip version of the file and the history of the file was lost. Signed-off-by: Miguel Torroja <miguel.torroja@gmail.com> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-24git-p4: fix handling of multi-word P4EDITORLibravatar Luke Diamand1-1/+1
This teaches git-p4 to pass the P4EDITOR variable to the shell for expansion, so that any command-line arguments are correctly handled. Without this, git-p4 can only launch the editor if P4EDITOR is solely the path to the binary, without any arguments. This also adjusts t9805, which relied on the previous behaviour. Suggested-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-11Merge branch 'va/p4-client-path'Libravatar Junio C Hamano1-4/+9
git p4 attempts to better handle branches in Perforce. * va/p4-client-path: git-p4: improve client path detection when branches are used t9801: check git-p4's branch detection with client spec enabled
2015-05-11Merge branch 'ls/p4-changes-block-size'Libravatar Junio C Hamano1-11/+41
"git p4" learned "--changes-block-size <n>" to read the changes in chunks from Perforce, instead of making one call to "p4 changes" that may trigger "too many rows scanned" error from Perforce. * ls/p4-changes-block-size: git-p4: use -m when running p4 changes
2015-04-23git-p4: improve client path detection when branches are usedLibravatar Vitor Antunes1-4/+9
Perforce allows client side file/directory remapping through the use of the client view definition that is part of the user's client spec. To support this functionality while branch detection is enabled it is important to determine the branch location in the workspace such that the correct files are patched before Perforce submission. Perforce provides a command that facilitates this process: p4 where. This patch does two things to fix improve file location detection when git-p4 has branch detection and use of client spec enabled: 1. Enable usage of "p4 where" when Perforce branches exist in the git repository, even when client specification is used. This makes use of the already existing function p4Where. 2. Allow identifying partial matches of the branch's depot path while processing the output of "p4 where". For robustness, paths will only match if ending in "/...". Signed-off-by: Vitor Antunes <vitor.hda@gmail.com> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-20git-p4: use -m when running p4 changesLibravatar Lex Spoon1-11/+41
Simply running "p4 changes" on a large branch can result in a "too many rows scanned" error from the Perforce server. It is better to use a sequence of smaller calls to "p4 changes", using the "-m" option to limit the size of each call. Signed-off-by: Lex Spoon <lex@lexspoon.org> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-04git-p4: fix filetype detection on files opened exclusivelyLibravatar Blair Holloway1-1/+1
If a Perforce server is configured to automatically set +l (exclusive lock) on add of certain file types, git p4 submit will fail during getP4OpenedType, as the regex doesn't expect the trailing '*exclusive*' from p4 opened: //depot/file.png#1 - add default change (binary+l) *exclusive* Signed-off-by: Blair Holloway <blair_holloway@playstation.sony.com> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-11Merge branch 'ld/p4-submit-hint'Libravatar Junio C Hamano1-1/+1
* ld/p4-submit-hint: git-p4: correct --prepare-p4-only instructions
2015-02-11git-p4: support excluding paths on syncLibravatar Luke Diamand1-10/+10
The clone subcommand has long had support for excluding subdirectories, but sync has not. This is a nuisance, since as soon as you do a sync, any changed files that were initially excluded start showing up. Move the "exclude" command-line option into the parent class; the actual behavior was already present there so it simply had to be exposed. Signed-off-by: Luke Diamand <luke@diamand.org> Reviewed-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-23git-p4: correct --prepare-p4-only instructionsLibravatar Luke Diamand1-1/+1
If you use git-p4 with the "--prepare-p4-only" option, then it prints the p4 command line to use. However, the command line was incorrect: the changelist specification must be supplied on standard input, not as an argument to p4. Signed-off-by: Luke Diamand <luke@diamand.org> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13git-p4: fix submit in non --prepare-p4-only modeLibravatar Maxime Coste1-6/+6
b4073bb3 (git-p4: Do not include diff in spec file when just preparing p4, 2014-05-24) broke git p4 submit, here is a proper fix, including proper handling for windows end of lines. Signed-off-by: Maxime Coste <frrrwww@gmail.com> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-27git-p4: Do not include diff in spec file when just preparing p4Libravatar Maxime Coste1-23/+26
The diff information render the spec file unusable as is by p4, do not include it when run with --prepare-p4-only so that the given file can be directly passed to p4. With --prepare-p4-only, git-p4 already tells the user it can use p4 submit with the generated spec file. This fails because of the diff being present in the file. Not including the diff fixes that. Without --prepare-p4-only, keeping the diff makes sense for a quick review of the patch before submitting it. And does not cause problems with p4 as we remove it programmatically. Signed-off-by: Maxime Coste <frrrwww@gmail.com> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-07Merge branch 'cl/p4-use-diff-tree'Libravatar Junio C Hamano1-1/+1
Fixes a regression in 1.9.0 with an obviously correct single-liner. * cl/p4-use-diff-tree: git-p4: format-patch to diff-tree change breaks binary patches
2014-05-07git-p4: format-patch to diff-tree change breaks binary patchesLibravatar Tolga Ceylan1-1/+1
When applying binary patches a full index is required. format-patch already handles this, but diff-tree needs '--full-index' argument to always output full index. When git-p4 runs git-apply to test the patch, git-apply rejects the patch due to abbreviated blob object names. This is the error message git-apply emits in this case: error: cannot apply binary patch to '<filename>' without full index line error: <filename>: patch does not apply Signed-off-by: Tolga Ceylan <tolga.ceylan@gmail.com> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-07git-p4: explicitly specify that HEAD is a revisionLibravatar Vlad Dogaru1-1/+1
'git p4 rebase' fails with the following message if there is a file named HEAD in the current directory: fatal: ambiguous argument 'HEAD': both revision and filename Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' Take the suggestion above and explicitly state that HEAD should be treated as a revision. Signed-off-by: Vlad Dogaru <vdogaru@ixiacom.com> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-22git p4: fix an error message when "p4 where" failsLibravatar Pete Wyckoff1-1/+1
When "p4 where" fails, for whatever reason, the error message tries to show an undefined variable. This minor bug applies only when using a client spec, and was introduced recently in 9d57c4a (git p4: implement view spec wildcards with "p4 where", 2013-08-30). Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-22git p4: handle files with wildcards when doing RCS scrubbingLibravatar Pete Wyckoff1-2/+2
Commit 9d7d446 (git p4: submit files with wildcards, 2012-04-29) fixed problems with handling files that had p4 wildcard characters, like "@" and "*". But it missed one case, that of RCS keyword scrubbing, which uses "p4 fstat" to extract type information. Fix it by calling wildcard_encode() on the raw filename. Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-22git p4 test: do not pollute /tmpLibravatar Pete Wyckoff1-1/+1
Generating the submit template for p4 uses tempfile.mkstemp(), which by default puts files in /tmp. For a test that fails, possibly on purpose, this is not cleaned up. Run with TMPDIR pointing into the trash directory so the temp files go away with the test results. To do this required some other minor changes. First, the editor is launched using system(editor + " " + template_file), using shell expansion to build the command string. This doesn't work if editor has a space in it. And is generally unwise as it's easy to fool the shell into doing extra work. Exec the args directly, without shell expansion. Second, without shell expansion, the trick of "P4EDITOR=:" used in the tests doesn't work. Use a real command, true, as the non-interactive editor for testing. Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-22git p4: work around p4 bug that causes empty symlinksLibravatar Pete Wyckoff1-1/+8
Damien Gérard highlights an interesting problem. Some p4 repositories end up with symlinks that have an empty target. It is not possible to create this with current p4, but they do indeed exist. The effect in git p4 is that "p4 print" on the symlink returns an empty string, confusing the curret symlink-handling code. Such broken repositories cause problems in p4 as well, even with no git involved. In p4, syncing to a change that includes a bogus symlink causes errors: //depot/empty-symlink - updating /home/me/p4/empty-symlink rename: /home/me/p4/empty-symlink: No such file or directory and leaves no symlink. In git, replicate the p4 behavior by ignoring these bad symlinks. If, in a later p4 revision, the symlink happens to point to something non-null, the symlink will be replaced properly. Add a big test for all this too. This happens to be a regression introduced by 1292df1 (git-p4: Fix occasional truncation of symlink contents., 2013-08-08) and appeared first in 1.8.5. But it shows up only in p4 repositories of dubious character, so can wait for a proper release. Tested-by: Damien Gérard <damien@iwi.me> Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-12Merge branch 'cl/p4-use-diff-tree'Libravatar Junio C Hamano1-1/+1
* cl/p4-use-diff-tree: git p4: Use git diff-tree instead of format-patch
2013-11-22git p4: Use git diff-tree instead of format-patchLibravatar Crestez Dan Leonard1-1/+1
The output of git format-patch can vary with user preferences. In particular setting diff.noprefix will break the "git apply" that is done as part of "git p4 submit". Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Crestez Dan Leonard <cdleonard@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-18Merge branch 'ks/p4-view-spec'Libravatar Junio C Hamano1-164/+59
* ks/p4-view-spec: git p4: implement view spec wildcards with "p4 where" git p4 test: sanitize P4CHARSET
2013-09-03git p4: implement view spec wildcards with "p4 where"Libravatar Kazuki Saitoh1-164/+59
"git p4" does not support many of the view wildcards, such as * and %%n. It only knows the common ... mapping, and exclusions. Redo the entire wildcard code around the idea of directly querying the p4 server for the mapping. For each commit, invoke "p4 where" with committed file paths as args and use the client mapping to decide where the file goes in git. This simplifies a lot of code, and adds support for all wildcards supported by p4. Downside is that there is probably a 20%-ish slowdown with this approach. [pw: redo code and tests] Signed-off-by: Kazuki Saitoh <ksaitoh560@gmail.com> Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-12git-p4: Fix occasional truncation of symlink contents.Libravatar Alexandru Juncu1-2/+6
Symlink contents in p4 print sometimes have a trailing new line character, but sometimes it doesn't. git-p4 should only remove the last character if that character is '\n'. Signed-off-by: Alex Juncu <ajuncu@ixiacom.com> Signed-off-by: Alex Badea <abadea@ixiacom.com> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-29many small typofixesLibravatar Ondřej Bílka1-1/+1
Signed-off-by: Ondřej Bílka <neleai@seznam.cz> Reviewed-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26Merge branch 'vl/typofix'Libravatar Junio C Hamano1-1/+1
* vl/typofix: random typofixes (committed missing a 't', successful missing an 's')
2013-06-19random typofixes (committed missing a 't', successful missing an 's')Libravatar Veres Lajos1-1/+1
Signed-off-by: Veres Lajos <vlajos@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-11git p4: avoid expanding client paths in chdirLibravatar Miklós Fazekas1-7/+22
The generic chdir() helper sets the PWD environment variable, as that is what is used by p4 to know its current working directory. Normally the shell would do this, but in git-p4, we must do it by hand. However, when the path contains a symbolic link, os.getcwd() will return the physical location. If the p4 client specification includes symlinks, setting PWD to the physical location causes p4 to think it is not inside the client workspace. It complains, e.g. Path /vol/bar/projects/foo/... is not under client root /p/foo One workaround is to use AltRoots in the p4 client specification, but it is cleaner to handle it directly in git-p4. Other uses of chdir still require setting PWD to an absolute path so p4 features like P4CONFIG work. See bf1d68f (git-p4: use absolute directory for PWD env var, 2011-12-09). [ pw: tweak patch and commit message ] Thanks-to: John Keeping <john@keeping.me.uk> Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-04Merge branch 'pw/git-p4-on-cygwin'Libravatar Junio C Hamano1-39/+80
Improve "git p4" on Cygwin. * pw/git-p4-on-cygwin: (21 commits) git p4: introduce gitConfigBool git p4: avoid shell when calling git config git p4: avoid shell when invoking git config --get-all git p4: avoid shell when invoking git rev-list git p4: avoid shell when mapping users git p4: disable read-only attribute before deleting git p4 test: use test_chmod for cygwin git p4: cygwin p4 client does not mark read-only git p4 test: avoid wildcard * in windows git p4 test: use LineEnd unix in windows tests too git p4 test: newline handling git p4: scrub crlf for utf16 files on windows git p4: remove unreachable windows \r\n conversion code git p4 test: translate windows paths for cygwin git p4 test: start p4d inside its db dir git p4 test: use client_view in t9806 git p4 test: avoid loop in client_view git p4 test: use client_view to build the initial client git p4: generate better error message for bad depot path git p4: remove unused imports ...
2013-02-01Merge branch 'bc/git-p4-for-python-2.4'Libravatar Junio C Hamano1-4/+26
With small updates to remove dependency on newer features of Python, keep git-p4 usable with older Python. * bc/git-p4-for-python-2.4: INSTALL: git-p4 does not support Python 3 git-p4.py: support Python 2.4 git-p4.py: support Python 2.5
2013-01-26git p4: introduce gitConfigBoolLibravatar Pete Wyckoff1-19/+26
Make the intent of "--bool" more obvious by returning a direct True or False value. Convert a couple non-bool users with obvious bool intent. Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-26git p4: avoid shell when calling git configLibravatar Pete Wyckoff1-6/+9
Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-26git p4: avoid shell when invoking git config --get-allLibravatar Pete Wyckoff1-1/+2
Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>