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

git-p4: speed up search for branch parent

2021-05-06T03:51:33Z

For every new branch that git-p4 imports, it needs to find the commit where it branched off its parent branch. While p4 doesn't record this information explicitly, the first changelist on a branch is usually an identical copy of the parent branch. The method searchParent() tries to find a commit in the history of the given "parent" branch whose tree exactly matches the initial changelist of the new branch, "target". The code iterates through the parent commits and compares each of them to this initial changelist using diff-tree. Since we already know the tree object name we are looking for, spawning diff-tree for each commit is wasteful. Use the "--format" option of "rev-list" to find out the tree object name of each commit in the history, and find the tree whose name is exactly the same as the tree of the target commit to optimize this. This results in a considerable speed-up, at least on Windows. On one Windows machine with a fairly large repository of about 16000 commits in the parent branch, the current code takes over 7 minutes, while the new code only takes just over 10 seconds for the same changelist: Before: $ time git p4 sync Importing from/into multiple branches Depot paths: //depot Importing revision 31274 (100.0%) Updated branches: b1 real 7m41.458s user 0m0.000s sys 0m0.077s After: $ time git p4 sync Importing from/into multiple branches Depot paths: //depot Importing revision 31274 (100.0%) Updated branches: b1 real 0m10.235s user 0m0.000s sys 0m0.062s Signed-off-by: Joachim Kuebart Helped-by: Junio C Hamano Helped-by: Luke Diamand Signed-off-by: Junio C Hamano

Merge branch 'dl/p4-encode-after-kw-expansion'

2021-01-16T05:48:47Z

Text encoding fix for "git p4". * dl/p4-encode-after-kw-expansion: git-p4: fix syncing file types with pattern

git-p4: fix syncing file types with pattern

2020-12-23T21:49:40Z

Example of pattern file type: text+k Text filtered through the p4 pattern regexp must be converted from string back to bytes, otherwise 'data' command for the fast-import will receive extra invalid characters, followed by the fast-import process error. CC: Yang Zhao Signed-off-by: Daniel Levin Signed-off-by: Junio C Hamano

Merge branch 'js/p4-default-branch'

2020-11-11T21:18:38Z

"git p4" now honors init.defaultBranch configuration. * js/p4-default-branch: p4: respect init.defaultBranch

p4: respect init.defaultBranch

2020-11-09T21:01:47Z

In `git p4 clone`, we hard-code the branch name `master` instead of looking what the _actual_ initial branch name is. Let's fix that. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

doc: fixing two trivial typos in Documentation/

2020-11-05T20:52:50Z

Fix misspelled "specified" and "occurred" in documentation and comments. Signed-off-by: Marlon Rac Cambasis Signed-off-by: Junio C Hamano

git-p4: use HEAD~$n to find parent commit for unshelve

2020-09-19T20:44:55Z

Found-by: Liu Xuhui (Jackson) Signed-off-by: Luke Diamand Signed-off-by: Junio C Hamano

Merge branch 'bk/p4-prepare-p4-only-fix'

2020-06-02T20:35:01Z

The "--prepare-p4-only" option is supposed to stop after replaying one changeset, but kept going (by mistake?) * bk/p4-prepare-p4-only-fix: git-p4.py: fix --prepare-p4-only error with multiple commits

git-p4.py: fix --prepare-p4-only error with multiple commits

2020-05-12T19:42:32Z

When using git p4 submit with the --prepare-p4-only option, the program should prepare a single p4 changelist and notify the user that more commits are pending and then stop processing. A bug has been introduced by the p4-changelist hook feature that causes the program to continue to try and process all pending changelists at the same time. The function applyCommit returns True when applying the commit was successful and the program should continue. However, when the optional flag --prepare-p4-only is set, the program should stop after the first application. Change the logic in the run method for P4Submit to check for the flag --prepare-p4-only after successfully completing the applyCommit method. Be aware - this change will fix the existing test error in t9807.23 for --prepare-p4-only. However there is insufficent coverage for this flag. If more than 1 commit is pending submission to P4, the method will properly prepare the P4 changelist, however it will still exit the application with an exitcode of 1. The current documentation does not define what the exit code should be in this condition. (See: https://git-scm.com/docs/git-p4#Documentation/git-p4.txt---prepare-p4-only) Signed-off-by: Ben Keene Signed-off-by: Junio C Hamano

git-p4: recover from inconsistent perforce history

2020-05-10T16:58:50Z

Perforce allows you commit files and directories with the same name, so you could have files //depot/foo and //depot/foo/bar both checked in. A p4 sync of a repository in this state fails. Deleting one of the files recovers the repository. When this happens we want git-p4 to recover in the same way as perforce. Note that Perforce has this change in their 2017.1 version: Bugs fixed in 2017.1 #1489051 (Job #2170) ** Submitting a file with the same name as an existing depot directory path (or vice versa) will now be rejected. so people hopefully will not creating damaged Perforce repos anymore, but "git p4" needs to be able to interact with already corrupt ones. Signed-off-by: Andrew Oakley Reviewed-by: Luke Diamand Signed-off-by: Junio C Hamano