git/git-p4.py, branch v2.3.4

git-p4: fix submit in non --prepare-p4-only mode

2014-06-13T18:04:04Z

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 Acked-by: Pete Wyckoff Signed-off-by: Junio C Hamano

git-p4: Do not include diff in spec file when just preparing p4

2014-05-27T19:35:15Z

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 Acked-by: Pete Wyckoff Signed-off-by: Junio C Hamano

Merge branch 'cl/p4-use-diff-tree'

2014-05-07T21:39:29Z

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

git-p4: format-patch to diff-tree change breaks binary patches

2014-05-07T17:27:22Z

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 '' without full index line error: : patch does not apply Signed-off-by: Tolga Ceylan Acked-by: Pete Wyckoff Signed-off-by: Junio C Hamano

git-p4: explicitly specify that HEAD is a revision

2014-04-07T22:37:12Z

'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 [...] -- [...]' Take the suggestion above and explicitly state that HEAD should be treated as a revision. Signed-off-by: Vlad Dogaru Acked-by: Pete Wyckoff Signed-off-by: Junio C Hamano

git p4: fix an error message when "p4 where" fails

2014-01-22T16:06:19Z

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 Signed-off-by: Junio C Hamano

git p4: handle files with wildcards when doing RCS scrubbing

2014-01-22T16:06:19Z

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 Signed-off-by: Junio C Hamano

git p4 test: do not pollute /tmp

2014-01-22T16:06:19Z

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 Signed-off-by: Junio C Hamano

git p4: work around p4 bug that causes empty symlinks

2014-01-22T16:05:04Z

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 Signed-off-by: Pete Wyckoff Signed-off-by: Junio C Hamano

Merge branch 'cl/p4-use-diff-tree'

2013-12-12T22:18:20Z

* cl/p4-use-diff-tree: git p4: Use git diff-tree instead of format-patch