We're coming up on when Python2 is end-of-lifed - we have until
January 1st 2020.
git-p4 uses python2, and doesn't work under python3 at all.
The problem is the conversions between Python3 unicode strings and git
(utf-8) and p4 (utf-8, except when it isn't).
I had a go at fixing this here:
http
On Tue, 27 Aug 2019 at 23:31, Junio C Hamano wrote:
>
> Andrey Mazo writes:
>
> > From: "Philip.McGraw"
> >
> > Avoid double-open exceptions on Windows platform when
> > calculating for lfs compressed size threshold
> > (git-p4.largeFileCompressedThreshold) comparisons.
> >
> > Take new approach
On Mon, 19 Aug 2019 at 18:30, Aaron Miller wrote:
>
> Hi all,
>
> Is it possible to `git p4 clone --detect-branches` from a Perforce
> path which contains bidirectional integrations?
>
> I've tried a bunch of things to get this to work, but here's an
> example which hopefully illustrates what I'm
On Fri, 12 Jul 2019 at 03:20, Andrey wrote:
>
> 25.06.2019, 13:44, "Junio C Hamano" :
> > Andrey writes:
> >
> >>> Thanks. When I ask "Is this ready", I am asking for opinion(s) from
> >>> third-party, not self nomination ;-)
> >>
> >> Ah, ok, sorry. :)
> >> I just haven't seen any related co
On Tue, 21 May 2019 at 23:50, Simon Williams wrote:
>
> 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,
> omiting files added in t
On Fri, 12 Apr 2019 at 12:39, Johannes Schindelin via GitGitGadget
wrote:
>
> From: Johannes Schindelin
>
> Most notably, it seems that macOS' APFS does not allow that.
Did you mean in the subject "ISO-8895-1" encoded or "ISO-8859-1" encoded?
It seems reasonable other than that!
>
> Signed-off
On Thu, 21 Mar 2019 at 22:32, Mazo, Andrey wrote:
>
> 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
On Fri, 22 Mar 2019 at 19:54, Mazo, Andrey wrote:
>
> Labels in Perforce are not global, but can be placed on a particular
> view/subdirectory.
> This might pose difficulties when importing only parts of Perforce depot into
> a git repository.
> For example:
> 1. Depot layout is as follows:
>
On Fri, 22 Mar 2019 at 19:54, Mazo, Andrey wrote:
>
> Our Perforce server experienced some kind of database corruption a few years
> ago.
> While the file data and revision history are mostly intact,
> some metadata for several changesets got lost.
I think it's not unheard of for P4 databases to
On Wed, 27 Feb 2019 at 09:49, SZEDER Gábor wrote:
>
> Hi Luke,
>
> I saw rare failures in test 6 'git p4 sync uninitialized repo' in
> 't9800-git-p4-basic.sh' on Travis CI, because the 'cleanup_git'
> function failed to do its job. The (redacted) trace looks like this:
Thanks for the *very* deta
On Sat, 9 Feb 2019 at 18:06, Junio C Hamano wrote:
>
> SZEDER Gábor writes:
>
> > On Fri, Feb 08, 2019 at 07:02:31PM +0000, Luke Diamand wrote:
> >> +# create a fake version of "p4" which returns a TicketExpiration based
> >> +# on $EXPIRY, for te
update-index --no-split-index" when base_oid in
> the index file is null. In this case we will not load
> istate->split_index->base but we dereference it anyway and are rewarded
> with a segfault. This should not happen anymore, but it's still wrong to
> dereference a potenti
On Sat, 9 Feb 2019 at 05:01, Duy Nguyen wrote:
>
> On Fri, Feb 8, 2019 at 11:39 PM Luke Diamand wrote:
> >
> > On Fri, 8 Feb 2019 at 10:02, Duy Nguyen wrote:
> > >
> > > On Wed, Feb 06, 2019 at 10:25:25AM +, Luke Diamand wrote:
> > > > I'
From: Luke Diamand
This tests for p4 ticket expiry by creating a ticket, and then waiting
long enough for the ticket to nearly expire. However, this is
unreliable.
Instead, create a 'fake' p4 which returns expiry times under the
control of the test script, and forwards other comma
On Fri, 8 Feb 2019 at 10:02, Duy Nguyen wrote:
>
> On Wed, Feb 06, 2019 at 10:25:25AM +, Luke Diamand wrote:
> > I've recently started seeing a lot of this message when doing a rebase:
> >
> >warning: could not freshen shared index
> > '/home/ldiama
On Thu, 7 Feb 2019 13:45:18 +0100 (STD)
Johannes Schindelin wrote:
> Hi Luke,
>
> On Wed, 6 Feb 2019, Luke Diamand wrote:
>
> > As per thread here, this removes the git-p4 ticket expiration
> > test, since it isn't really that useful.
> >
> > https
dir/file &&
> + rm -rf add_dir_add_file_del_file add_dir_add_file_del_dir &&
> + touch add_dir_add_file_del_file add_dir_add_file_del_dir &&
> + p4 add add_dir_add_file_del_file add_dir_add_file_del_dir &&
> + p4 submit -d "add conflicting" &&
> +
> + p4 delete -k add_file_add_dir_del_file &&
> + p4 delete -k add_file_add_dir_del_dir/file &&
> + p4 delete -k add_dir_add_file_del_file &&
> + p4 delete -k add_dir_add_file_del_dir/file &&
> + p4 submit -d "delete conflicting"
> + )
> +'
> +
> +test_expect_success 'clone with git-p4' '
> + git p4 clone --dest="$git" //depot/@all
> +'
> +
> +test_expect_success 'check final contents' '
> + test_path_is_dir "$git/add_file_add_dir_del_file" &&
> + test_path_is_file "$git/add_file_add_dir_del_dir" &&
> + test_path_is_dir "$git/add_dir_add_file_del_file" &&
> + test_path_is_file "$git/add_dir_add_file_del_dir"
> +'
> +
> +test_expect_success 'kill p4d' '
> + kill_p4d
> +'
> +
> +test_done
> --
> 2.19.2
>
--
Luke Diamand
r expiry results
the test requires.
Ideally git-p4 would look at the expiry time before starting
any long operations, and cleanup gracefully if there is not
enough time left. But that's quite hard to do.
Signed-off-by: Luke Diamand
---
t/t9833-errors.sh | 27 ---
As per thread here, this removes the git-p4 ticket expiration
test, since it isn't really that useful.
https://marc.info/?l=git&m=154946136416003&w=2
Luke Diamand (1):
git-p4: remove ticket expiry test
t/t9833-errors.sh | 27 ---
1 file changed,
On Wed, 6 Feb 2019 at 11:11, SZEDER Gábor wrote:
>
> On Wed, Feb 06, 2019 at 11:33:21AM +0100, Johannes Schindelin wrote:
> > Hi Luke,
> >
> > in a private Azure Pipeline (sorry...) I noticed an intermittent problem
> > in the p4 tests on osx-gcc.
> >
> > I would point you to a public log, but the
I've recently started seeing a lot of this message when doing a rebase:
warning: could not freshen shared index
'/home/ldiamand/git/dev_full/.git/worktrees/gcc8-take-2/sharedindex.'
(There's a repo called dev_full, and I've got a worktree where I'm
worki
On Mon, 4 Feb 2019 at 23:28, Jeff King wrote:
>
> On Mon, Feb 04, 2019 at 01:45:35PM +, Luke Diamand wrote:
>
> > I tried to do a partial clone, but it gave me a "bad pack header". Is
> > there anything I can do to debug this?
> >
> > I did "gi
I tried to do a partial clone, but it gave me a "bad pack header". Is
there anything I can do to debug this?
I did "git config uploadpack.allowfilter true" in my repo.
Then I went to a scratch directory and did:
$ git clone --filter=blob:limit=10M ssh://localhost/~/git/my_big_repo
remote: Enumerat
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
Acked-by: Andrey Mazo
---
git-p4.py| 2 ++
t/t9807-git-p4
errors from Perforce
such as:
//depot/src - needs tofile //depot/dst
Submit aborted -- fix problems then use 'p4 submit -c 1234'
Signed-off-by: Luke Diamand
Acked-by: Andrey Mazo
---
t/t9807-git-p4-submit.sh | 57 +---
1 file changed, 54 insert
This updates the patchset to support copy, as suggested by Andrey.
Luke Diamand (2):
git-p4: add failing test for shelved CL update involving move/copy
git-p4: handle update of moved/copied files when updating a shelve
git-p4.py| 2 ++
t/t9807-git-p4-submit.sh | 57
Perforce requires a complete list of files being operated on. If
git is updating an existing shelved changelist, then any files
which are moved were not being added to this list.
Signed-off-by: Luke Diamand
---
git-p4.py| 1 +
t/t9807-git-p4-submit.sh | 2 +-
2 files changed, 2
Updated as per comments from Junio, Eric.
https://public-inbox.org/git/20190113135815.11286-1-l...@diamand.org/
Luke Diamand (2):
git-p4: add failing test for shelved CL update involving move
git-p4: handle update of moved files when updating a shelve
git-p4.py| 1 +
t
from Perforce
such as:
//depot/src - needs tofile //depot/dst
Submit aborted -- fix problems then use 'p4 submit -c 1234'
Signed-off-by: Luke Diamand
---
t/t9807-git-p4-submit.sh | 51 +---
1 file changed, 48 insertions(+), 3 deletions(-)
diff
I found this bug recently in git-p4 - updating a shelved changelist where files
are being moved doesn't work. The destination of any moves needs to be
added to the list of files passed to P4.
Luke Diamand (2):
git-p4: add failing test for shelved CL update involving move
git-p4: handle u
Perforce requires a complete list of files being operated on. If
git is updating an existing shelved changelist, then any files
which are moved were not being added to this list.
Signed-off-by: Luke Diamand
---
git-p4.py| 1 +
t/t9807-git-p4-submit.sh | 2 +-
2 files changed, 2
Updating a shelved P4 changelist where one or more of the files have
been moved does not work. Add a test for this.
Signed-off-by: Luke Diamand
---
t/t9807-git-p4-submit.sh | 53 +---
1 file changed, 50 insertions(+), 3 deletions(-)
diff --git a/t/t9807-git
On Mon, 7 Jan 2019 at 20:51, Peter Osterlund wrote:
>
> 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.
This is caused by my earlier change in
git-p4 can map a "git move" operation to a Perforce "move" operation.
But by default this is disabled. You then end up with a P4 commit
where the file is deleted, and a fresh file is created with the same
contents at the new location at revision #1.
Rename detection gets enabled either with the "-
On Sun, 6 Jan 2019 at 22:48, Peter Osterlund wrote:
>
> Hi,
>
> When I use "git p4 sync" to update a git repository from a perforce depot,
> the operation fails with error message:
>
> failure accessing depot: unknown error code info
>
> When I run "p4 login -s" from a shell it reports:
>
>
On Fri, 9 Nov 2018 at 10:48, Jeff King wrote:
>
> On Fri, Nov 09, 2018 at 10:44:10AM +, Luca Milanesio wrote:
>
> > > On 9 Nov 2018, at 10:42, Jeff King wrote:
> > >
> > > Git Merge 2019 is happening on February 1st. There will be a
> > > Contributor's Summit the day before. Here are the deta
On Tue, 16 Oct 2018 at 05:27, Junio C Hamano wrote:
>
> Luke Diamand writes:
>
> > This is the same as my earlier patch other than fixing the
> > documentation to reflect the change to the destination branch,
> > as noticed by Junio.
>
> Also you set up when-fi
On Mon, 15 Oct 2018 at 16:02, Johannes Schindelin
wrote:
>
> Hi Luke,
>
> On Mon, 15 Oct 2018, Luke Diamand wrote:
>
> > On Mon, 15 Oct 2018 at 11:12, Johannes Schindelin via GitGitGadget
> > wrote:
> > >
> > > From: Johannes Schindelin
> > &g
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/.
Signed-off-by: Luke Diamand
tas.
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' operatio
igned-off-by: Luke Diamand
---
git-p4.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index 7fab255584..5701bad06a 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2775,7 +2775,10 @@ def streamOneP4File(self, file, contents):
relPath = self.stripRep
This is the same as my earlier patch other than fixing the
documentation to reflect the change to the destination branch,
as noticed by Junio.
Luke Diamand (3):
git-p4: do not fail in verbose mode for missing 'fileSize' key
git-p4: unshelve into refs/remotes/p4-unshelved, not
re
On Fri, 12 Oct 2018 at 19:19, Luke Diamand wrote:
>
> On Fri, 12 Oct 2018 at 14:45, Junio C Hamano wrote:
> >
> > Luke Diamand writes:
> >
> > > The branch detection code looks for branches under refs/remotes/p4/...
> > > and can end up getting
On Mon, 15 Oct 2018 at 11:12, Johannes Schindelin via GitGitGadget
wrote:
>
> From: Johannes Schindelin
>
> This should be more reliable than the current method, and prepares the
> test suite for a consistent way to clean up before re-running the tests
> with different options.
>
I'm finding tha
On Fri, 12 Oct 2018 at 14:45, Junio C Hamano wrote:
>
> Luke Diamand writes:
>
> > 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 t
tas.
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' operatio
being
that it no longer unshelves into refs/remotes/p4/master/unshelved, but
instead into refs/remotes/p4-unshelved.
That's because the git-p4 branch detection gets confused by branches
appearing in refs/remotes/p4.
Luke Diamand (3):
git-p4: do not fail in verbose mode for missing 'fi
igned-off-by: Luke Diamand
---
git-p4.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index 7fab255584..5701bad06a 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2775,7 +2775,10 @@ def streamOneP4File(self, file, contents):
relPath = self.stripRep
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/.
Signed-off-by: Luke Diamand
On 5 September 2018 at 13:39, Johannes Schindelin
wrote:
> Hi Luke,
>
> On Wed, 5 Sep 2018, Luke Diamand wrote:
>
>> On 4 September 2018 at 12:09, Johannes Schindelin
>> wrote:
>> >
>> > On Tue, 4 Sep 2018, Eric Sunshine wrote:
>> >
>>
On 4 September 2018 at 12:09, Johannes Schindelin
wrote:
> Hi Eric,
>
> On Tue, 4 Sep 2018, Eric Sunshine wrote:
>
>> On Mon, Sep 3, 2018 at 5:10 PM Johannes Schindelin via GitGitGadget
>> wrote:
>> > So let's do something different in VSTS: let's run all the tests with
>> > `--quiet` first, and
On 31 July 2018 at 16:40, Junio C Hamano wrote:
> Luke Diamand writes:
>
>> I think there is an error in the test harness.
>>
>> On 31 July 2018 at 10:46, SZEDER Gábor wrote:
>>>> + test_must_fail git-p4 submit --dry-run >errs 2>&1 &
I think there is an error in the test harness.
On 31 July 2018 at 10:46, SZEDER Gábor wrote:
>> + test_must_fail git-p4 submit --dry-run >errs 2>&1 &&>
>> + ! grep "Would apply" err
It writes to the file "errs" but then looks for the message in "err".
Luke
On 30 July 2018 at 20:07, Junio C Hamano wrote:
> Chen Bin writes:
>
>> 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
>> ---
>
> Luke, does this version look good to you?
>
Yes,
On 26 July 2018 at 10:21, Eric Sunshine wrote:
> On Wed, Jul 25, 2018 at 10:08 PM chen bin wrote:
>> The hook does not receive any information or input from git. The
>> original requirement
>> comes from my colleague. He want to run unit test automatically before
>> submitting code
>> to remote r
On 23 July 2018 at 12:27, Chen Bin wrote:
> Hook pre-p4-submit is executed before git-p4 actually submits code.
> If the hook exits with non-zero value, submit process will abort.
Looks good to me - could you add some documentation please
(Documentation/git-p4.txt).
Thanks!
Luke
>
> Signed-of
On 26 June 2018 at 08:29, Eric Sunshine wrote:
> These tests intentionally break the &&-chain to manually check the exit
> code of invoked commands which they expect to fail, and invert that
> local expected failure into a successful exit code for the test overall.
> Such manual exit code manipula
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
---
git-p4.py | 248 +++---
1 file changed, 124 insertions
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
---
git-
In Python3, basestring no longer exists, so use this workaround.
Signed-off-by: Luke Diamand
---
git-p4.py | 16
1 file changed, 16 insertions(+)
diff --git a/git-p4.py b/git-p4.py
index 67865d14aa..f127ebce27 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -27,6 +27,22 @@
import
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
---
git-p4.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-p4.py b/git-
that is
quite a bit harder (but not impossible).
I have some further changes to address this, but they are quite a bit
more invasive, and not actually working yet. It's based very loosely on the
"polystr()" suggestion from Eric on this list.
It still works fine with Python2.7
See PEP3127. Works fine with python2 as well.
Signed-off-by: Luke Diamand
---
git-p4.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index 714e442d7c..b449db1cc9 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -1841,7 +1841,7 @@ def applyCommit(self, id
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
---
git-p4.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4
On 16 June 2018 at 10:58, merlo...@yahoo.fr wrote:
> Yes Luke, my colleagues and I, we care ! Our repository is p4 (choice of the
> high management, sigh...). Some of us are working natively on p4, but others
> like me are working on git through git-p4. We often want to share pieces of
> codes to
On 15 May 2018 at 11:01, Luke Diamand wrote:
> This is a git-p4 unshelve command which detects when extra
> changes are going to be included, and refuses to unhshelve.
>
> As in my earlier unshelve change, this uses git fast-import
> to do the actual delta generation, but now che
On 12 June 2018 at 22:53, Eric Sunshine wrote:
> On Tue, Jun 12, 2018 at 5:49 PM, Luke Diamand wrote:
>> Thanks. While on the subject of git-p4, I thought I should mention
>> that I've been looking at getting git-p4 to work with Python3.
>>
>> I've got
On 12 June 2018 at 22:35, Junio C Hamano wrote:
> Luke Diamand writes:
>
>> On 12 June 2018 at 18:10, Junio C Hamano wrote:
>>> Luke Diamand writes:
>>>
>>>> This is an updated version of the set of changes I posted recently,
>>>> follo
On 12 June 2018 at 18:10, Junio C Hamano wrote:
> Luke Diamand writes:
>
>> This is an updated version of the set of changes I posted recently,
>> following comments on the list:
>>
>> disable automatic sync after git-p4 submit:
>> https://marc.info/?l=gi
93815326&w=2
adapt the block size automatically on git-p4 submit:
https://marc.info/?l=git&m=152819004315688&w=2
- Spelling corrections (Eric)
- Improved comments (Eric)
- Exception class hierarchy fix (Merland)
- test simplification (Eric)
Luke Diamand (6):
git-p4: disable-rebase
ize, 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
---
git-p4.py | 27 +--
t/t9818-git-p4-block.sh | 8
2 files changed, 29 insert
attempted, and tries to print a meaningful
error message if it fails.
Signed-off-by: Luke Diamand
---
git-p4.py | 55 +
t/t9833-errors.sh | 78 +++
2 files changed, 133 insertions(+)
create mode 100755 t/t9833
),
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
x27;t useful.
Signed-off-by: Luke Diamand
---
Documentation/git-p4.txt | 8
git-p4.py| 31 ---
2 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 3d83842e47..f0de3b891b 100644
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
---
Documentation/git-p4.txt | 5 -
git-p4.py
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
---
git-p4.py | 2 +-
1 file changed
>>
>>> ErrorId MsgDb::MaxResults = { ErrorOf( ES_DB, 32,
>>> E_FAILED, EV_ADMIN, 1 ), "Request too large (over %maxResults%); see
>>> 'p4 help maxresults'." } ;//NOTRANS
>>> ErrorId MsgDb::MaxScanRows = { ErrorOf( ES_DB, 61,
>>> E_FAILED, EV_ADMIN, 1 ), "Too many ro
On 5 June 2018 at 20:41, Eric Sunshine wrote:
> On Tue, Jun 5, 2018 at 6:56 AM Luke Diamand wrote:
>> On 5 June 2018 at 10:54, Eric Sunshine wrote:
>> > On Tue, Jun 5, 2018 at 5:14 AM Luke Diamand wrote:
>> >> +m = re.search('Too
On 5 June 2018 at 11:49, Merland Romain wrote:
>
>> @@ -91,6 +93,13 @@ def p4_build_cmd(cmd):
>> real_cmd = ' '.join(real_cmd) + ' ' + cmd
>> else:
>> real_cmd += cmd
>> +
>> +# now check that we can actually talk to the server
>> +global p4_access_checked
>> +if no
On 5 June 2018 at 10:54, Eric Sunshine wrote:
> On Tue, Jun 5, 2018 at 5:14 AM Luke Diamand wrote:
>> 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.
>&
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
---
git-p4.py | 2 +-
1 file changed
ange
~~~
The function p4CmdList() has been taught to raise an exception when it
gets an error, and in particular, to notice and report the two "too many
results" errors.
The code that does the blocking can now start out with a nice large
block size, and then reduce it if it se
ize, 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
---
git-p4.py | 26 +-
t/t9818-git-p4-block.sh | 11 +++
2 files changed, 32 insert
),
P4ServerException (the server sent us an error code) and
P4RequestSizeException (we requested too many rows/results from the
server database).
This makes 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
would be nice to also check for ticket expiration during long
Perforce operations, but this change does not attempt to do that.
Luke Diamand (1):
git-p4: better error reporting when p4 fails
git-p4.py | 55 +
t/t9833-errors.sh | 78
attempted, and tries to print a meaningful
error message if it fails.
Signed-off-by: Luke Diamand
---
git-p4.py | 55 +
t/t9833-errors.sh | 78 +++
2 files changed, 133 insertions(+)
create mode 100755 t/t9833
x27;t useful.
Signed-off-by: Luke Diamand
---
Documentation/git-p4.txt | 8
git-p4.py| 31 ---
2 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 3d83842e47..8f6a7543fd 100644
h the sync.
I imagine other people with large git-p4 projects do something similar
and have the same problem.
This also updates Merland's recent submit-selection change so that both
options can be set via configuration rather than being set on the
command line.
Luke Diamand (2):
git-p
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
---
Documentation/git-p4.txt | 5 -
git-p4.py
On 4 June 2018 at 14:57, Junio C Hamano wrote:
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'. The ones marked with '.' do not appear in any of
> the integration branches, but I am stil
On 24 May 2018 at 01:02, Junio C Hamano wrote:
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'. The ones marked with '.' do not appear in any of
> the integration branches, but I am stil
This just removes the verbose print change, which will end up causing
conflicts later since it's also being fixed in another commit.
Discussed here:
https://public-inbox.org/git/byapr08mb38455afe85ae6b04eb31ef92da...@byapr08mb3845.namprd08.prod.outlook.com/
Luke Diamand (1):
git-p4
er 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
---
Documentation/git-p4.txt |
On 23 May 2018 at 17:41, Mazo, Andrey wrote:
>> The last one (i.e. "even if it is verbose, if fileSize is not
>> reported, do not write the verbose output") does not look like it is
>> limited to the unshelve feature, so it might, even though it is a
>> one-liner, deserve to be a separate preparat
er 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
---
Documentation/git-p4.txt |
This is v5 of my git-p4 unshelve patch. It fixes a problem found by
SZEDER Gábor with newer versions of Perforce (2016 vs 2015).
Luke Diamand (1):
git-p4: add unshelve command
Documentation/git-p4.txt | 32 ++
git-p4.py| 215 ---
t
On 22 May 2018 at 11:15, SZEDER Gábor wrote:
> On Tue, May 22, 2018 at 10:41 AM, Luke Diamand wrote:
>> SZEDER Gábor found that the unshelve tests fail with newer
>> versions of Perforce (2016 vs 2015).
>>
>> The problem arises because when a file is added in a P4
This fixes a problem found by SZEDER Gábor with newer versions of
the Perforce database engine (2016 onwards). It looks like the
behaviour has change subtly when reporting the revision of newly
added files. The fix is to just use the file status.
Luke Diamand (1):
git-p4: unshelve: use action
epot/new#1 add
We can detect that a file has been added simply by using the
file status ("add") instead, rather than the depot revision,
which is what this change does.
This also fixes a few verbose prints used for debugging this
to be more friendly.
Signed-off-by: Luke Diamand
---
gi
On 21 May 2018 at 23:09, Luke Diamand wrote:
> On 21 May 2018 at 22:39, SZEDER Gábor wrote:
>>> diff --git a/t/t9832-unshelve.sh b/t/t9832-unshelve.sh
>
> ...
> ...
>
>>> +'
>>
>> This test fails on my box and on Travis CI (in all four standa
1 - 100 of 407 matches
Mail list logo
