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

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

p4: retrieve the right revision of the file in UTF-16 codepath

2015-05-27T23:23:02Z

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

git-p4: fix handling of multi-word P4EDITOR

2015-05-24T18:50:12Z

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

Merge branch 'va/p4-client-path'

2015-05-11T21:23:48Z

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

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

2015-05-11T21:23:46Z

"git p4" learned "--changes-block-size " 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

git-p4: improve client path detection when branches are used

2015-04-23T17:17:02Z

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