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

Merge branch 'ls/p4-translation-failure' into maint

2015-11-03T23:32:32Z

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

Merge branch 'ld/p4-import-labels' into maint

2015-11-03T23:32:28Z

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

git-p4: handle "Translation of file content failed"

2015-09-22T19:15:17Z

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

git-p4: fix P4 label import for unprocessed commits

2015-08-28T19:02:58Z

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

git-p4: do not terminate creating tag for unknown commit

2015-08-28T19:02:56Z

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

git-p4: honor core.ignorecase when using P4 client specs

2015-08-28T17:33:16Z

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

Merge branch 'ld/p4-changes-block-size'

2015-06-24T19:21:57Z

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

Merge branch 'mt/p4-depotFile-at-version'

2015-06-11T16:29:55Z

* mt/p4-depotFile-at-version: p4: retrieve the right revision of the file in UTF-16 codepath

git-p4: fixing --changes-block-size handling

2015-06-10T15:29:17Z

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

Merge branch 'ld/p4-editor-multi-words'

2015-06-05T19:17:38Z

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