summaryrefslogtreecommitdiff
path: root/git-p4.py
AgeCommit message (Collapse)AuthorFilesLines
2020-02-11git-p4: create new function run_git_hookLibravatar Ben Keene1-7/+69
This commit is in preparation of introducing new p4 submit hooks. The current code in the python script git-p4.py makes the assumption that the git hooks can be executed by subprocess.call() function. However, when git is run on Windows, this may not work as expected. The subprocess.call() does not cover all the use cases for properly executing the various types of executable files on Windows. Prepare for remediation by adding a new function, run_git_hook, that takes 2 parameters: * the short filename of an optionally registered git hook * an optional list of parameters The run_git_hook function will honor the existing behavior seen in the current code for executing the p4-pre-submit hook: * Hooks are looked for in core.hooksPath directory. * If core.hooksPath is not set, then the current .git/hooks directory is checked. * If the hook does not exist, the function returns True. * If the hook file is not accessible, the function returns True. * If the hook returns a zero exit code when executed, the function return True. * If the hook returns a non-zero exit code, the function returns False. Add the following additional functionality if git-p4.py is run on Windows. * If hook file is not located without an extension, search for any file in the associated hook directory (from the list above) that has the same name but with an extension. * If the file is still not found, return True (the hook is missing) Add a new function run_hook_command() that wraps the OS dependent functionality for actually running the subprocess.call() with OS dependent behavior: If a hook file exists on Windows: * If there is no extension, set the launch executable to be SH.EXE - Look for SH.EXE under the environmental variable EXEPATH in the bin/ directory. - If %EXEPATH%/bin/sh.exe exists, use this as the actual executable. - If %EXEPATH%/bin/sh.exe does not exist, use sh.exe - Execute subprocess.call() without the shell (shell=False) * If there is an extension, execute subprocess.call() with teh shell (shell=True) and consider the file to be the executable. The return value from run_hook_command() is the subprocess.call() return value. These functions are added in this commit, but are only staged and not yet used. Signed-off-by: Ben Keene <seraphire@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-11git-p4: rewrite prompt to be Windows compatibleLibravatar Ben Keene1-1/+4
The existing function prompt(prompt_text) does not work correctly when run on Windows 10 bash terminal when launched from the sourcetree GUI application. The stdout is not flushed properly so the prompt text is not displayed to the user until the next flush of stdout, which is quite confusing. Change this method by: * Adding flush to stderr, stdout, and stdin * Use readline from sys.stdin instead of raw_input. The existing strip().lower() are retained. Signed-off-by: Ben Keene <seraphire@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-02Merge branch 'bk/p4-misc-usability'Libravatar Junio C Hamano1-32/+42
Miscellaneous small UX improvements on "git-p4". * bk/p4-misc-usability: git-p4: show detailed help when parsing options fail git-p4: yes/no prompts should sanitize user text
2019-12-16git-p4: show detailed help when parsing options failLibravatar Ben Keene1-1/+6
When a user provides invalid parameters to git-p4, the program reports the failure but does not provide the correct command syntax. Add an exception handler to the command-line argument parser to display the command's specific command line parameter syntax when an exception is thrown. Rethrow the exception so the current behavior is retained. Signed-off-by: Ben Keene <seraphire@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-16git-p4: yes/no prompts should sanitize user textLibravatar Ben Keene1-31/+36
When prompting the user interactively for direction, the tests are not forgiving of user input format. For example, the first query asks for a yes/no response. If the user enters the full word "yes" or "no" or enters a capital "Y" the test will fail. Create a new function, prompt(prompt_text) where * prompt_text is the text prompt for the user * returns a single character where valid return values are found by inspecting prompt_text for single characters surrounded by square brackets This new function must prompt the user for input and sanitize it by converting the response to a lower case string, trimming leading and trailing spaces, and checking if the first character is in the list of choices. If it is, return the first letter. Change the current references to raw_input() to use this new function. Since the method requires the returned text to be one of the available choices, remove the loop from the calling code that handles response verification. Thanks-to: Denton Liu <liu.denton@gmail.com> Signed-off-by: Ben Keene <seraphire@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-11git-p4: honor lfs.storage configuration variableLibravatar r.burenkov1-2/+8
"git lfs" allows users to specify the custom storage location with the configuration variable `lfs.storage`, but when interacting with GitLFS pointers, "git p4" always uses the hardcoded default that is the `.git/lfs/` directory, without paying attention to the configuration. Use the value configured in `lfs.storage`, if exists, as all the "git" operations do, for consistency. Signed-off-by: r.burenkov <panzercheg@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-06git-p4: auto-delete named temporary fileLibravatar Philip.McGraw1-7/+6
Avoid double-open exceptions on Windows platform when calculating for lfs compressed size threshold (git-p4.largeFileCompressedThreshold) comparisons. Take new approach using the NamedTemporaryFile() file-like object as input to the ZipFile() which auto-deletes after implicit close leaving with scope. Original code had double-open exception on Windows platform because file still open from NamedTemporaryFile() using generated filename instead of object. Thanks to Andrey for patiently suggesting several iterations on this change for avoiding exceptions! Also print error details after resulting IOError to make debugging cause of exception less mysterious when it has nothing to do with "git version recent enough." Signed-off-by: Philip.McGraw <Philip.McGraw@bentley.com> Reviewed-by: Andrey Mazo <ahippo@yandex.com> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-09Merge branch 'am/p4-branches-excludes'Libravatar Junio C Hamano1-17/+27
"git p4" update. * am/p4-branches-excludes: git-p4: respect excluded paths when detecting branches git-p4: add failing test for "git-p4: respect excluded paths when detecting branches" git-p4: don't exclude other files with same prefix git-p4: add failing test for "don't exclude other files with same prefix" git-p4: don't groom exclude path list on every commit git-p4: match branches case insensitively if configured git-p4: add failing test for "git-p4: match branches case insensitively if configured" git-p4: detect/prevent infinite loop in gitCommitByP4Change()
2019-06-17Merge branch 'mm/p4-unshelve-windows-fix'Libravatar Junio C Hamano1-1/+1
The command line to invoke a "git cat-file" command from inside "git p4" was not properly quoted to protect a caret and running a broken command on Windows, which has been corrected. * mm/p4-unshelve-windows-fix: p4 unshelve: fix "Not a valid object name HEAD0" on Windows
2019-05-28p4 unshelve: fix "Not a valid object name HEAD0" on WindowsLibravatar Mike Mueller1-1/+1
git p4 unshelve was failing with these errors: fatal: Not a valid object name HEAD0 Command failed: git cat-file commit HEAD^0 (git version 2.21.0.windows.1, python 2.7.16) The pOpen call used by git-p4 to invoke the git command can take either a string or an array as a first argument. The array form is preferred because platform-specific escaping of special characters will be handled automatically.(https://docs.python.org/2/library/subprocess.html) The extractLogMessageFromGitCommit method was, however, using the string form and so the caret (^) character in the HEAD^0 argument was not being escaped on Windows. The caret happens to be the escape character, which is why the git command was receiving HEAD0. The behaviour can be confirmed by typing ECHO HEAD^0 at the command- prompt, which emits HEAD0. The solution is simply to use the array format of passing the command to fOpen, which is recommended and used in other parts of this code anyway. Signed-off-by: Mike Mueller <mike.mueller@moodys.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28git-p4: allow unshelving of branched filesLibravatar Simon Williams1-1/+1
When unshelving a changelist, git-p4 tries to work out the appropriate parent commit in a given branch (default: HEAD). To do this, it looks at the state of any pre-existing files in the target Perforce branch, omitting files added in the shelved changelist. Currently, only files added (or move targets) are classed as new. However, files integrated from other branches (i.e. a 'branch' action) also need to be considered as added, for this purpose. Signed-off-by: Simon Williams <simon@no-dns-yet.org.uk> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-02git-p4: respect excluded paths when detecting branchesLibravatar Mazo, Andrey1-2/+1
Currently, excluded paths are only handled in the following cases: * no branch detection; * branch detection with using clientspec. However, excluded paths are not respected in case of branch detection without using clientspec. Fix this by consulting the list of excluded paths when splitting files across branches. Signed-off-by: Andrey Mazo <amazo@checkvideo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-02git-p4: don't exclude other files with same prefixLibravatar Mazo, Andrey1-7/+14
Make sure not to exclude files unintentionally if exclude paths are specified without a trailing /. I.e., don't exclude "//depot/file_dont_exclude" if run with "-//depot/file". Do this by ensuring that paths without a trailing "/" are only matched completely. Also, abort path search on the first match as a micro-optimization. Signed-off-by: Andrey Mazo <amazo@checkvideo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-02git-p4: don't groom exclude path list on every commitLibravatar Mazo, Andrey1-5/+7
Currently, `cloneExclude` array is being groomed (by removing trailing "...") on every changeset. (since `extractFilesFromCommit()` is called on every imported changeset) As a micro-optimization, do it once while parsing arguments. Also, prepend "/" and remove trailing "..." at the same time. Signed-off-by: Andrey Mazo <amazo@checkvideo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-02git-p4: match branches case insensitively if configuredLibravatar Mazo, Andrey1-2/+2
git-p4 knows how to handle case insensitivity in file paths if core.ignorecase is set. However, when determining a branch for a file, it still does a case-sensitive prefix match. This may result in some file changes to be lost on import. For example, given the following commits 1. add //depot/main/file1 2. add //depot/DirA/file2 3. add //depot/dira/file3 4. add //depot/DirA/file4 and "branchList = main:DirA" branch mapping, commit 3 will be lost. So, do branch search case insensitively if running with core.ignorecase set. Teach splitFilesIntoBranches() to use the p4PathStartsWith() function for path prefix matches instead of always case-sensitive match. Signed-off-by: Andrey Mazo <amazo@checkvideo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-02git-p4: detect/prevent infinite loop in gitCommitByP4Change()Libravatar Mazo, Andrey1-1/+3
Under certain circumstances, gitCommitByP4Change() can enter an infinite loop resulting in `git p4 sync` hanging forever. The problem is that `git rev-list --bisect <latest> ^<earliest>` can return `<latest>`, which would result in reinspecting <latest> and potentially an infinite loop. This can happen when importing just a subset of P4 repository and/or with explicit "--changesfile" option. A real-life example: """ looking in ref refs/remotes/p4/mybranch for change 26894 using bisect... Reading pipe: git rev-parse refs/remotes/p4/mybranch trying: earliest latest 4daff81c520a82678e1ef347f2b5e97258101ae1 Reading pipe: git rev-list --bisect 4daff81c520a82678e1ef347f2b5e97258101ae1 Reading pipe: git cat-file commit 147f5d3292af2e1cc4a56a7b96db845144c68486 current change 25339 trying: earliest ^147f5d3292af2e1cc4a56a7b96db845144c68486 latest 4daff81c520a82678e1ef347f2b5e97258101ae1 Reading pipe: git rev-list --bisect 4daff81c520a82678e1ef347f2b5e97258101ae1 ^147f5d3292af2e1cc4a56a7b96db845144c68486 Reading pipe: git cat-file commit 51db83df9d588010d0bd995641c85aa0408a5bb9 current change 25420 trying: earliest ^51db83df9d588010d0bd995641c85aa0408a5bb9 latest 4daff81c520a82678e1ef347f2b5e97258101ae1 Reading pipe: git rev-list --bisect 4daff81c520a82678e1ef347f2b5e97258101ae1 ^51db83df9d588010d0bd995641c85aa0408a5bb9 Reading pipe: git cat-file commit e8f83909ceb570f5a7e48c2853f3c5d8207cea52 current change 25448 trying: earliest ^e8f83909ceb570f5a7e48c2853f3c5d8207cea52 latest 4daff81c520a82678e1ef347f2b5e97258101ae1 Reading pipe: git rev-list --bisect 4daff81c520a82678e1ef347f2b5e97258101ae1 ^e8f83909ceb570f5a7e48c2853f3c5d8207cea52 Reading pipe: git cat-file commit 09a48eb7acd594dce52e06681be9c366e1844d66 current change 25521 trying: earliest ^09a48eb7acd594dce52e06681be9c366e1844d66 latest 4daff81c520a82678e1ef347f2b5e97258101ae1 Reading pipe: git rev-list --bisect 4daff81c520a82678e1ef347f2b5e97258101ae1 ^09a48eb7acd594dce52e06681be9c366e1844d66 Reading pipe: git cat-file commit 4daff81c520a82678e1ef347f2b5e97258101ae1 current change 26907 trying: earliest ^09a48eb7acd594dce52e06681be9c366e1844d66 latest 4daff81c520a82678e1ef347f2b5e97258101ae1 Reading pipe: git rev-list --bisect 4daff81c520a82678e1ef347f2b5e97258101ae1 ^09a48eb7acd594dce52e06681be9c366e1844d66 Reading pipe: git cat-file commit 4daff81c520a82678e1ef347f2b5e97258101ae1 current change 26907 trying: earliest ^09a48eb7acd594dce52e06681be9c366e1844d66 latest 4daff81c520a82678e1ef347f2b5e97258101ae1 Reading pipe: git rev-list --bisect 4daff81c520a82678e1ef347f2b5e97258101ae1 ^09a48eb7acd594dce52e06681be9c366e1844d66 Reading pipe: git cat-file commit 4daff81c520a82678e1ef347f2b5e97258101ae1 current change 26907 ... """ The fix is two-fold: * detect an infinite loop and die right away instead of looping forever; * make sure, `git rev-list --bisect` can't return "latestCommit" again by excluding it from the rev-list range explicitly. Signed-off-by: Andrey Mazo <amazo@checkvideo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-05Merge branch 'ld/git-p4-shelve-update-fix'Libravatar Junio C Hamano1-0/+2
"git p4" failed to update a shelved change when there were moved files, which has been corrected. * ld/git-p4-shelve-update-fix: git-p4: handle update of moved/copied files when updating a shelve git-p4: add failing test for shelved CL update involving move/copy
2019-01-18git-p4: handle update of moved/copied files when updating a shelveLibravatar Luke Diamand1-0/+2
Perforce requires a complete list of files being operated on. If git is updating an existing shelved changelist, then any files which are moved or copied were not being added to this list. Signed-off-by: Luke Diamand <luke@diamand.org> Acked-by: Andrey Mazo <amazo@checkvideo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-07git-p4: fix problem when p4 login is not necessaryLibravatar Peter Osterlund1-0/+2
In a perforce setup where login is not required, communication fails because p4_check_access does not understand the response from the p4 client. Fixed by detecting and ignoring the "info" response. Signed-off-by: Peter Osterlund <peterosterlund2@gmail.com> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-16git-p4: fully support unshelving changelistsLibravatar Luke Diamand1-36/+48
The previous git-p4 unshelve support would check for changes in Perforce to the files being unshelved since the original shelve, and would complain if any were found. This was to ensure that the user wouldn't end up with both the shelved change delta, and some deltas from other changes in their git commit. e.g. given fileA: the quick brown fox change1: s/the/The/ <- p4 shelve this change change2: s/fox/Fox/ <- p4 submit this change git p4 unshelve 1 <- FAIL This change teaches the P4Unshelve class to always create a parent commit which matches the P4 tree (for the files being unshelved) at the point prior to the P4 shelve being created (which is reported in the p4 description for a shelved changelist). That then means git-p4 can always create a git commit matching the P4 shelve that was originally created, without any extra deltas. The user might still need to use the --origin option though - there is no way for git-p4 to work out the versions of all of the other *unchanged* files in the shelve, since this information is not recorded by Perforce. Additionally this fixes handling of shelved 'move' operations. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-16git-p4: unshelve into refs/remotes/p4-unshelved, not refs/remotes/p4/unshelvedLibravatar Luke Diamand1-1/+2
The branch detection code looks for branches under refs/remotes/p4/... and can end up getting confused if there are unshelved changes in there as well. This happens in the function p4BranchesInGit(). Instead, put the unshelved changes into refs/remotes/p4-unshelved/<N>. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-12git-p4: do not fail in verbose mode for missing 'fileSize' keyLibravatar Luke Diamand1-1/+4
If deleting or moving a file, sometimes P4 doesn't report the file size. The code handles this just fine but some logging crashes. Stop this happening. There was some earlier discussion on the list about this: https://public-inbox.org/git/xmqq1sqpp1vv.fsf@gitster.mtv.corp.google.com/ Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-01git-p4: add the `p4-pre-submit` hookLibravatar Chen Bin1-1/+15
The `p4-pre-submit` hook is executed before git-p4 submits code. If the hook exits with non-zero value, submit process not start. Signed-off-by: Chen Bin <chenbin.sh@gmail.com> Reviewed-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-19git-p4: python3: fix octal constantsLibravatar Luke Diamand1-1/+1
See PEP3127. Works fine with python2 as well. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-19git-p4: python3: use print() functionLibravatar Luke Diamand1-124/+124
Replace calls to print ... with the function form, print(...), to allow use with python3 as well as python2.x. Converted using 2to3 (and some hand-editing). Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-19git-p4: python3: basestring workaroundLibravatar Luke Diamand1-0/+16
In Python3, basestring no longer exists, so use this workaround. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-19git-p4: python3: remove backticksLibravatar Luke Diamand1-1/+1
Backticks around a variable are a deprecated alias for repr(). This has been removed in python3, so just use the string representation instead, which is equivalent. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-19git-p4: python3: replace dict.has_key(k) with "k in dict"Libravatar Luke Diamand1-39/+39
Python3 does not have the dict.has_key() function, so replace all such calls with "k in dict". This will still work with python2.6 and python2.7. Converted using 2to3 (plus some hand-editing) Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-19git-p4: python3: replace <> with !=Libravatar Luke Diamand1-1/+1
The <> string inequality operator (which doesn't seem to be even documented) no longer exists in python3. Replace with !=. This still works with python2. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-18Merge branch 'ld/git-p4-updates'Libravatar Junio C Hamano1-24/+156
"git p4" updates. * ld/git-p4-updates: git-p4: auto-size the block git-p4: narrow the scope of exceptions caught when parsing an int git-p4: raise exceptions from p4CmdList based on error from p4 server git-p4: better error reporting when p4 fails git-p4: add option to disable syncing of p4/master with p4 git-p4: disable-rebase: allow setting this via configuration git-p4: add options --commit and --disable-rebase
2018-06-12git-p4: auto-size the blockLibravatar Luke Diamand1-6/+21
git-p4 originally would fetch changes in one query. On large repos this could fail because of the limits that Perforce imposes on the number of items returned and the number of queries in the database. To fix this, git-p4 learned to query changes in blocks of 512 changes, However, this can be very slow - if you have a few million changes, with each chunk taking about a second, it can be an hour or so. Although it's possible to tune this value manually with the "--changes-block-size" option, it's far from obvious to ordinary users that this is what needs doing. This change alters the block size dynamically by looking for the specific error messages returned from the Perforce server, and reducing the block size if the error is seen, either to the limit reported by the server, or to half the current block size. That means we can start out with a very large block size, and then let it automatically drop down to a value that works without error, while still failing correctly if some other error occurs. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-12git-p4: narrow the scope of exceptions caught when parsing an intLibravatar Luke Diamand1-1/+1
The current code traps all exceptions around some code which parses an integer, and then talks to Perforce. That can result in errors from Perforce being ignored. Change the code to only catch the integer conversion exceptions. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-12git-p4: raise exceptions from p4CmdList based on error from p4 serverLibravatar Luke Diamand1-4/+40
This change lays some groundwork for better handling of rowcount errors from the server, where it fails to send us results because we requested too many. It adds an option to p4CmdList() to return errors as a Python exception. The exceptions are derived from P4Exception (something went wrong), P4ServerException (the server sent us an error code) and P4RequestSizeException (we requested too many rows/results from the server database). This makes the code that handles the errors a bit easier. The default behavior is unchanged; the new code is enabled with a flag. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-12git-p4: better error reporting when p4 failsLibravatar Luke Diamand1-0/+55
Currently when p4 fails to run, git-p4 just crashes with an obscure error message. For example, if the P4 ticket has expired, you get: Error: Cannot locate perforce checkout of <path> in client view This change checks whether git-p4 can talk to the Perforce server when the first P4 operation is attempted, and tries to print a meaningful error message if it fails. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-12git-p4: add option to disable syncing of p4/master with p4Libravatar Luke Diamand1-11/+20
Add an option to the git-p4 submit command to disable syncing with Perforce. This is useful for the case where a git-p4 mirror has been setup on a server somewhere, running from (e.g.) cron, and developers then clone from this. Having the local cloned copy also sync from Perforce just isn't useful. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-12git-p4: disable-rebase: allow setting this via configurationLibravatar Luke Diamand1-1/+1
This just lets you set the --disable-rebase option with the git configuration options git-p4.disableRebase. If you're using this option, you probably want to set it all the time for a given repo. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-12git-p4: add options --commit and --disable-rebaseLibravatar Romain Merland1-6/+23
On a daily work with multiple local git branches, the usual way to submit only a specified commit was to cherry-pick the commit on master then run git-p4 submit. It can be very annoying to switch between local branches and master, only to submit one commit. The proposed new way is to select directly the commit you want to submit. Add option --commit to command 'git-p4 submit' in order to submit only specified commit(s) in p4. On a daily work developping software with big compilation time, one may not want to rebase on his local git tree, in order to avoid long recompilation. Add option --disable-rebase to command 'git-p4 submit' in order to disable rebase after submission. Thanks-to: Cedric Borgese <cedric.borgese@gmail.com> Reviewed-by: Luke Diamand <luke@diamand.org> Signed-off-by: Romain Merland <merlorom@yahoo.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-01Merge branch 'ld/p4-unshelve'Libravatar Junio C Hamano1-36/+177
"git p4" learned to "unshelve" shelved commit from P4. * ld/p4-unshelve: git-p4: add unshelve command
2018-05-24git-p4: add unshelve commandLibravatar Luke Diamand1-36/+177
This can be used to "unshelve" a shelved P4 commit into a git commit. For example: $ git p4 unshelve 12345 The resulting commit ends up in the branch: refs/remotes/p4/unshelved/12345 If that branch already exists, it is renamed - for example the above branch would be saved as p4/unshelved/12345.1. git-p4 checks that the shelved changelist is based on files which are at the same Perforce revision as the origin branch being used for the unshelve (HEAD by default). If they are not, it will refuse to unshelve. This is to ensure that the unshelved change does not contain other changes mixed-in. The reference branch can be changed manually with the "--origin" option. The change adds a new Unshelve command class. This just runs the existing P4Sync code tweaked to handle a shelved changelist. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-11git-p4: change "commitish" typo to "committish"Libravatar Ævar Arnfjörð Bjarmason1-3/+3
This was the only occurrence of "commitish" in the tree, but as the log will reveal we've had others in the past. Fixes up code added in 00ad6e3182 ("git-p4: work with a detached head", 2015-11-21). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22git-p4: update multiple shelved change listsLibravatar Luke Diamand1-15/+26
--update-shelve can now be specified multiple times on the command-line, to update multiple shelved changelists in a single submit. This then means that a git patch series can be mirrored to a sequence of shelved changelists, and (relatively easily) kept in sync as changes are made in git. Note that Perforce does not really support overlapping shelved changelists where one change touches the files modified by another. Trying to do this will result in merge conflicts. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-23treewide: correct several "up-to-date" to "up to date"Libravatar Martin Ågren1-1/+1
Follow the Oxford style, which says to use "up-to-date" before the noun, but "up to date" after it. Don't change plumbing (specifically send-pack.c, but transport.c (git push) also has the same string). This was produced by grepping for "up-to-date" and "up to date". It turned out we only had to edit in one direction, removing the hyphens. Fix a typo in Documentation/git-diff-index.txt while we're there. Reported-by: Jeffrey Manian <jeffrey.manian@gmail.com> Reported-by: STEVEN WHITE <stevencharleswhitevoices@gmail.com> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13git-p4: filter for {'code':'info'} in p4CmdListLibravatar Miguel Torroja1-3/+6
The function p4CmdList accepts a new argument: skip_info. When set to True it ignores any 'code':'info' entry (skip_info=False by default). That allows us to fix some of the tests in t9831-git-p4-triggers.sh known to be broken with verobse p4 triggers Signed-off-by: Miguel Torroja <miguel.torroja@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13git-p4: parse marshal output "p4 -G" in p4 changesLibravatar Miguel Torroja1-28/+57
The option -G of p4 (python marshal output) gives more context about the data being output. That's useful when using the command "change -o" as we can distinguish between warning/error line and real change description. This fixes the case where a p4 trigger for "p4 change" is set and the command git-p4 submit is run. Signed-off-by: Miguel Torroja <miguel.torroja@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-16git-p4: don't use name-rev to get current branchLibravatar Luke Diamand1-6/+1
git-p4 was using "git name-rev" to find out the current branch. That is not safe, since if multiple branches or tags point at the same revision, the result obtained might not be what is expected. Instead use "git symbolic-ref". Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-16git-p4: add read_pipe_text() internal functionLibravatar Luke Diamand1-3/+28
The existing read_pipe() function returns an empty string on error, but also returns an empty string if the command returns an empty string. This leads to ugly constructions trying to detect error cases. Add read_pipe_text() which just returns None on error. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-16Merge branch 'ls/p4-path-encoding'Libravatar Junio C Hamano1-10/+14
When "git p4" imports changelist that removes paths, it failed to convert pathnames when the p4 used encoding different from the one used on the Git side. This has been corrected. * ls/p4-path-encoding: git-p4: fix git-p4.pathEncoding for removed files
2017-02-10git-p4: fix git-p4.pathEncoding for removed filesLibravatar Lars Schneider1-10/+14
In a9e38359e3 we taught git-p4 a way to re-encode path names from what was used in Perforce to UTF-8. This path re-encoding worked properly for "added" paths. "Removed" paths were not re-encoded and therefore different from the "added" paths. Consequently, these files were not removed in a git-p4 cloned Git repository because the path names did not match. Fix this by moving the re-encoding to a place that affects "added" and "removed" paths. Add a test to demonstrate the issue. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Reviewed-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-02Merge branch 'gv/mingw-p4-mapuser'Libravatar Junio C Hamano1-1/+1
"git p4" did not work well with multiple git-p4.mapUser entries on Windows. * gv/mingw-p4-mapuser: git-p4: fix git-p4.mapUser on Windows
2017-01-30git-p4: fix git-p4.mapUser on WindowsLibravatar George Vanburgh1-1/+1
When running git-p4 on Windows, with multiple git-p4.mapUser entries in git config - no user mappings are applied to the generated repository. Reproduction Steps: 1. Add multiple git-p4.mapUser entries to git config on a Windows machine 2. Attempt to clone a p4 repository None of the user mappings will be applied. This issue is actually caused by gitConfigList, using split(os.linesep) to convert the output of git config --get-all into a list. On Windows, os.linesep is equal to '\r\n' - however git.exe returns configuration with a line seperator of '\n'. This leads to the list returned by gitConfigList containing only one element - which contains the full output of git config --get-all in string form, which causes problems for the code introduced to getUserMapFromPerforceServer in 10d08a149d ("git-p4: map a P4 user to Git author name and email address", 2016-03-01) This issue should be caught by the test introduced in 10d08a1, however would require running on Windows to reproduce. Using splitlines solves this issue, by splitting config on all typical delimiters ('\n', '\r\n' etc.) Signed-off-by: George Vanburgh <gvanburgh@bloomberg.net> Reviewed-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>