Re: git-p4 out of memory for very large repository

On 23/08/13 02:12, Corey Thompson wrote: Hello, Has anyone actually gotten git-p4 to clone a large Perforce repository? Yes. I've cloned repos with a couple of Gig of files. I have one codebase in particular that gets to about 67%, then consistently gets get-fast-import (and often times a

Re: git-p4 out of memory for very large repository

I think I've cloned files as large as that or larger. If you just want to clone this and move on, perhaps you just need a bit more memory? What's the size of your physical memory and swap partition? Per process memory limit? On 23 Aug 2013 12:59, Corey Thompson cmt...@gmail.com wrote: On

Re: git-p4 out of memory for very large repository

I guess you could try changing the OOM score for git-fast-import. change /proc/pid/oomadj. I think a value of -31 would make it very unlikely to be killed. On 29/08/13 23:46, Pete Wyckoff wrote: cmt...@gmail.com wrote on Wed, 28 Aug 2013 11:41 -0400: On Mon, Aug 26, 2013 at 09:47:56AM -0400,

Is there a way to find out which commit git rebase --skip skipped?

If I do git rebase --skip, is there a way to find out the commit SHA that was skipped (other than just parsing the output of the command) ? I'd like to modify git-p4 so that it can automatically skip past conflicting changes, but I'd like it to keep a log of which commits were skipped. Thanks,

Re: [PATCH 00/12] git p4: submit conflict handling

On 17/08/12 00:35, Pete Wyckoff wrote: These patches rework how git p4 deals with conflicts that arise during a git p4 submit. These may arise due to changes that happened in p4 since the last git p4 sync. Luke: I especially wanted to get this out as you suggested that you had a different way

Re: [PATCH 02/12] git p4 test: use p4d -L option to suppress log messages

On 17/08/12 00:35, Pete Wyckoff wrote: Send p4d output to a logfile in the $TRASH_DIRECTORY. Its messages add no value to testing. I'm not totally sold on this; I still fairly frequently see weird errors from p4d and these help me work out what's going on. For example, at the moment if you

Re: [PATCH 03/12] git p4: gracefully fail if some commits could not be applied

On 17/08/12 00:35, Pete Wyckoff wrote: If a commit fails to apply cleanly to the p4 tree, an interactive prompt asks what to do next. In all cases (skip, apply, write), the behavior after the prompt had a few problems. Change it so that it does not claim erroneously that all commits were

Re: Is there a way to find out which commit git rebase --skip skipped?

On 16/08/12 16:43, Junio C Hamano wrote: Luke Diamandl...@diamand.org writes: If I do git rebase --skip, is there a way to find out the commit SHA that was skipped (other than just parsing the output of the command) ? There currently isn't, and I do not think it is doable in general when

Re: [PATCHv2 01/12] git p4 test: remove bash-ism of combined export/assignment

Looks good to me, ack. On 09/09/12 21:16, Pete Wyckoff wrote: Signed-off-by: Pete Wyckoffp...@padd.com --- t/lib-git-p4.sh | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh index 2d753ab..482eeac 100644 --- a/t/lib-git-p4.sh +++

Re: [PATCHv2 03/12] git p4: remove submit failure options [a]pply and [w]rite

git-p4 won't be quite the same without these completely misleading and confusing messages :-) Ack. On 09/09/12 21:16, Pete Wyckoff wrote: When a patch failed to apply, these interactive options offered to: 1) apply the patch anyway, leaving reject (.rej) files around, or, 2)

Re: [PATCHv2 04/12] git p4: move conflict prompt into run, add [q]uit input

I'll need to supply a followup patch to ensure that a config option can override the prompt. Ack. On 09/09/12 21:16, Pete Wyckoff wrote: When applying a commit to the p4 workspace fails, a prompt asks what to do next. This belongs up in run() instead of in applyCommit(), where run() can

Re: [PATCHv2 05/12] git p4: standardize submit cancel due to unchanged template

Ack. On 09/09/12 21:16, Pete Wyckoff wrote: When editing the submit template, if no change was made to it, git p4 offers a prompt Submit anyway?. Answering no cancels the submit. Previously, a no answer behaves like a [s]kip answer to the failed-patch prompt, in that it proceeded to try to

Re: [PATCHv2 01/12] git p4 test: remove bash-ism of combined export/assignment

On 16/09/12 07:05, Junio C Hamano wrote: Luke Diamandl...@diamand.org writes: Looks good to me, ack. Thanks; is this an ack for the entire series, or are you expecting further back-and-forth with Pete before the whole thing is ready? An ack for the whole series. I'm just going through the

Re: [PATCHv2 01/12] git p4 test: remove bash-ism of combined export/assignment

On 17/09/12 05:50, Junio C Hamano wrote: Luke Diamandl...@diamand.org writes: On 16/09/12 07:05, Junio C Hamano wrote: Luke Diamandl...@diamand.org writes: Looks good to me, ack. Thanks; is this an ack for the entire series, or are you expecting further back-and-forth with Pete before

Re: git p4 submit failing

Just a thought, but check the files that are failing to see if they've got RCS keywords in them ($Id$, $File$, $Date$, etc). These cause all sorts of nasty problems. That's assuming it's definitely not a CRLF line ending problem on Windows. On Thu, Apr 11, 2013 at 8:01 PM, Christopher Yee Mon

Re: 3 way merge during git p4 rebase is attempting to reapply past commits

On 08/05/13 00:12, Christopher Yee Mon wrote: Hello, I have a setup where I have a remote non-bare repo cloned from a perforce workspace. It is used as a remote repo that people clone into their own user repos, make commits to, then push back into the remote repo. Why is your p4 clone non-bare?

Re: git p4 diff-tree ambiguous argument error

Is this using NFS, or local storage? On 10/07/14 18:30, Bill Door wrote: $ git p4 sync --detect-branches --import-labels //main@all ... Lots of useful information elided fatal: ambiguous argument 'git-p4-tmp/8031': unknown revision or path not in the working tree. Use '--' to separate paths

Re: [PATCH] Correction to git-p4 exclude change

(Resending as plain text). I could be wrong about this, but my correction above doesn't seem to be in 'next'. Does that mean (reading your last what's cooking) that the broken version is going to go out to 'master' soon? Thanks, Luke On 5 February 2015 at 08:19, Luke Diamand l...@diamand.org

[PATCH] git-p4: support exclude in 'git p4 sync'

the documentation and adds a test-case. Thanks, Luke And yes, I'm back to using version control systems other than git :-( Luke Diamand (1): git-p4: support excluding paths on sync Documentation/git-p4.txt |6 ++-- git-p4.py | 18 ++-- t/t9817-git-p4-exclude.sh

[PATCH] git-p4: support excluding paths on sync

was already present there so it simply had to be exposed. Signed-off-by: Luke Diamand l...@diamand.org --- Documentation/git-p4.txt |6 ++-- git-p4.py | 18 ++-- t/t9817-git-p4-exclude.sh | 71 + 3 files changed, 83 insertions

Re: git-p4 is not cloning perforce code properly

When you say skipping, can you be more specific please? What command line are you using? If I want to clone the P4 tree at the current revision, I do something like: $ git p4 clone //depot/sometree/... That gets me just a single revision. If I want all revisions back to the start of time, I

[PATCH] git-p4: correct exclude change

The previous change for excluding paths in the sync subcommand was incorrect, missing a comma, preventing git-p4 from working. Signed-off-by: Luke Diamand l...@diamand.org --- git-p4.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-p4.py b/git-p4.py index 6ff0b76

[PATCH] Correction to git-p4 exclude change

wrong with it. There's a small shell syntax problem (missing esac) but after fixing that it still fails, so I'm not sure what's happening yet. It was discussed a while back. Luke Diamand (1): git-p4: correct exclude change git-p4.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion

[PATCH] git-p4: correct --prepare-p4-only instructions

If you use git-p4 with the --prepare-p4-only option, then it prints the p4 command line to use. However, the command line was incorrect: the changelist specification must be supplied on standard input, not as an argument to p4. Signed-off-by: Luke Diamand l...@diamand.org --- git-p4.py | 2 +- 1

[PATCH] git-p4: correct --prepare-p4-only instructions

Luke Diamand (1): git-p4: correct --prepare-p4-only instructions git-p4.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.1.3.1037.g95a6691.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo

Re: [PATCH] git=p4.py rebase now honor's client spec

On 19/03/15 21:58, brian m. carlson wrote: On Thu, Mar 19, 2015 at 12:28:09PM +, Sam Bishop wrote: When using the git-p4.py script, I found that if I used a client spec when cloning out a perforce repository, and then using a git-p4.py rebase, that the rebase command would be using the

Re: [PATCH] t9814: Guarantee only one source exists in git-p4 copy tests

I'm on holiday this week, so I'll not get a chance to look at these properly until next week. Luke On 30 March 2015 at 04:03, Junio C Hamano gits...@pobox.com wrote: Vitor Antunes vitor@gmail.com writes: * Modify source file (file2) before copying the file. * Check that only file2 is

Re: [PATCH] git-p4: fix filetype detection on files opened exclusively

(+Pete for interest). On 31 March 2015 at 22:54, Holloway, Blair blair_hollo...@playstation.sony.com wrote: If a Perforce server is configured to automatically set +l (exclusive lock) on add of certain file types, git p4 submit will fail during getP4OpenedType, as the regex doesn't expect the

[PATCHv2 3/4] git-p4: fix filetype detection on files opened exclusively

/file.png#1 - add default change (binary+l) *exclusive* Signed-off-by: Blair Holloway blair_hollo...@playstation.sony.com Acked-by: Luke Diamand l...@diamand.org --- git-p4.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-p4.py b/git-p4.py index ff132b2..d43482a 100755

[PATCHv2 1/4] git-p4: fix small bug in locked test scripts

-by: Luke Diamand l...@diamand.org --- t/t9816-git-p4-locked.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t9816-git-p4-locked.sh b/t/t9816-git-p4-locked.sh index e71e543..ce0eb22 100755 --- a/t/t9816-git-p4-locked.sh +++ b/t/t9816-git-p4-locked.sh @@ -41,7 +41,7

[PATCHv2 4/4] git-p4: update locked test case

The add-new-file and copy-existing-file tests from t9816-git-p4-locked.sh now pass. Update the test case accordingly. Signed-off-by: Luke Diamand l...@diamand.org --- t/t9816-git-p4-locked.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t9816-git-p4-locked.sh b/t

[PATCHv2 2/4] git-p4: small fix for locked-file-move-test

crashes. At present, git-p4 has no support for detecting that a file has been locked and reporting it to the user, so this is the expected outcome. Signed-off-by: Luke Diamand l...@diamand.org --- t/t9816-git-p4-locked.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t

[PATCHv2 0/4] git-p4: fix filetype detection on files opened exclusively

This is a followup series to Blair's patch to fix filetype detection on files opened exclusively. It updates the git-p4 unit tests to catchup with that fix, fixing a couple of small bugs in the original tests. Holloway, Blair (1): git-p4: fix filetype detection on files opened exclusively Luke

Re: [PATCH] git-p4: Use -m when running p4 changes

On 11 April 2015 at 16:17, Lex Spoon l...@lexspoon.org wrote: Signed-off-by: Lex Spoon l...@lexspoon.org --- This patch addresses a problem I am running into with a client. I am attempting to mirror their Perforce repository into Git, and on certain branches their Perforce server is

Re: [PATCH v3] git-p4: Use -m when running p4 changes

...@lexspoon.org Reviewed-by: Junio C Hamano gits...@pobox.com Reviewed-by: Luke Diamand l...@diamand.org I could be wrong about this, but it looks like importNewBranches() is taking an extra argument, but that isn't reflected in the place where it gets called. I think it just got missed

Re: [PATCH v4] git-p4: Use -m when running p4 changes

rows scanned error from the Perforce server. It is better to use a sequence of smaller calls to p4 changes, using the -m option to limit the size of each call. Signed-off-by: Lex Spoon l...@lexspoon.org Reviewed-by: Junio C Hamano gits...@pobox.com Reviewed-by: Luke Diamand l...@diamand.org

Re: git-p4 Question

On 23/04/15 14:42, FusionX86 wrote: Hi Luke, I found a silly mistake I was making in the command I've been using. The folder under the depot should have been capitalized, but it wasn't. Also, I expected that if there was a problem with the command, it would fail with some message instead of

Re: [PATCH] fast-import: add options to enable/disable case folding

On 18/04/15 08:36, Mike Hommey wrote: On Fri, Apr 17, 2015 at 11:44:00AM -0700, Junio C Hamano wrote: So perhaps we should rip the case folding out altogether instead? The entry for the change in the Release Notes may say: * git fast-import incorrectly case-folded the paths recorded in

Re: git-p4 Question

On 24/04/15 15:36, FusionX86 wrote: I get an error if I misspell part of the path. For example, if I type //depot/maain instead of //depot/main I will get the no such files message you indicated. BUT using incorrect case like //depot/main instead of //depot/Main doesn't return any error, but

Re: [PATCH V3 0/2] git-p4: improve client path detection when branches are used

On 22/04/15 18:11, Junio C Hamano wrote: Vitor Antunes vitor@gmail.com writes: The updates introduced in the third revision of these two patches consist only on updates to the commit messages to better clarify what they implement. Vitor Antunes (2): t9801: check git-p4's branch

Re: [PATCH V3 0/2] git-p4: improve client path detection when branches are used

On 23 April 2015 at 09:37, Vitor Antunes vitor@gmail.com wrote: That was a good combination to test. In fact, I am using such a client spec at my work place to exclude the import from Perforce of a folder that only contains binary files, but I never even considered to add files to that

Re: [PATCH v4] git-p4: Use -m when running p4 changes

On 20/04/15 16:25, Lex Spoon wrote: On Mon, Apr 20, 2015 at 11:15 AM, Luke Diamand l...@diamand.org wrote: Sorry - could you resubmit your patch (PATCHv4 it will be) with this change squashed in please? It will make life much easier, especially for Junio! The message you just responded

Re: git-p4 Question

On 20/04/15 17:41, FusionX86 wrote: Hello, Hopefully this is an appropriate place to ask questions about git-p4. I started at a company that wants to migrate from Perforce to Git. I'm new to Perforce and have been trying to learn just enough about it to get through this migration. Anyway, I've

Re: git-p4 Question

in the future. Thanks for the suggestions and pointers, it's much appreciated. On Mon, Apr 20, 2015 at 1:26 PM, Luke Diamand l...@diamand.org wrote: On 20/04/15 17:41, FusionX86 wrote: Hello, Hopefully this is an appropriate place to ask questions about git-p4. I started at a company that wants

Re: [PATCH] git-p4: add failing tests for case-folding p4d

(Adding Pete, Vitor, and Fusion in case they have any thoughts on working with P4 servers that do case-folding, or at least failing gracefully). On 29/04/15 00:01, Lex Spoon wrote: The last comment in the test took me a minute to decipher. I would suggest no repo path called LC instead of no

[PATCH] git-p4: prevent --chain-lint failure

. Signed-off-by: Luke Diamand l...@diamand.org --- t/t9814-git-p4-rename.sh | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh index 99bb71b..14f9dc3 100755 --- a/t/t9814-git-p4-rename.sh +++ b/t/t9814-git-p4-rename.sh

[PATCH] Fixup test-lint error in git-p4 t9814 test

if this is the right way to fix this. Thanks, Luke Luke Diamand (1): git-p4: prevent --chain-lint failure t/t9814-git-p4-rename.sh | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) -- 2.3.4.48.g223ab37 -- To unsubscribe from this list: send the line unsubscribe git in the body

[PATCH] git-p4: add failing tests for case-folding p4d

When p4d runs on a case-folding OS, git-p4 can end up getting very confused. This adds failing tests to demonstrate the problem. Signed-off-by: Luke Diamand l...@diamand.org --- t/lib-git-p4.sh| 2 +- t/t9819-git-p4-case-folding.sh | 54

[PATCH] git-p4: add failing tests for case-folding in p4d

test cases that illustrate the problem. The next step is to figure out where it's going wrong, and how it should actually behave. Luke Diamand (1): git-p4: add failing tests for case-folding p4d t/lib-git-p4.sh| 2 +- t/t9819-git-p4-case-folding.sh | 54

[PATCHv3] git-p4: t9814: prevent --chain-lint failure

Use test_lazy_prereq to setup prerequisites for the p4 move test. This both makes the test simpler and clearer, and also means it no longer fails the new --chain-lint tests. Suggested-by: Jeff King p...@peff.net Signed-off-by: Luke Diamand l...@diamand.org --- t/t9814-git-p4-rename.sh | 11

[PATCHv3] Fixup test-lint error in git-p4 t9814 test

Using Jeff's suggestion of converting the t9814 test to use test_lazy_prereq makes the test a lot clearer, and as a bonus, also fixes the --chain-lint error. Version 3 of the patch corrects a small typo in the commit message of version 2. Luke Diamand (1): git-p4: t9814: prevent --chain-lint

[PATCHv2] git-p4: t9814: prevent --chain-lint failure

Use test_lazy_prereq to setup prerequisites for the p4 move test. This both makes the test simpler and clearer, and also means they no longer fail the new --chain-lint tests. Suggested-by: Jeff King p...@peff.net Signed-off-by: Luke Diamand l...@diamand.org --- t/t9814-git-p4-rename.sh | 11

[PATCHv2] Fixup test-lint error in git-p4 t9814 test

Using Jeff's suggestion of converting the t9814 test to use test_lazy_prereq makes the test a lot clearer, and as a bonus, also fixes the --chain-lint error. Thanks, Luke Luke Diamand (1): git-p4: t9814: prevent --chain-lint failure t/t9814-git-p4-rename.sh | 11 +++ 1 file changed

Re: [PATCH] git-p4: add failing tests for case-folding in p4d

On 28/04/15 10:08, Luke Diamand wrote: Lex found out recently that when git-p4 is asked to clone a repo and the case of the repo is incorrect (but otherwise correct) that git-p4, instead of reporting an error, appears to work fine, but actually produces an empty repo. This can be quite confusing

Re: git p4 clone - exclude file types

On 18/05/15 18:59, FusionX86 wrote: Hello, Anyone know of a way to 'git p4 clone' and exclude files by type or name? For example, I want to clone a depot, but not pull down any .exe files. Haven't been able to find an answer in docs or other searches. I think you can use a client spec which

[PATCHv2 1/2] git-p4: add failing test for P4EDITOR handling

Add test case that git-p4 handles a setting of P4EDITOR that takes arguments, e.g. gvim -f Signed-off-by: Luke Diamand l...@diamand.org Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t9820-git-p4-editor-handling.sh | 38 ++ 1 file changed, 38 insertions

[PATCHv2 2/2] git-p4: fix handling of multi-word P4EDITOR

on the previous behaviour. Suggested-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Luke Diamand l...@diamand.org Signed-off-by: Junio C Hamano gits...@pobox.com --- git-p4.py | 2 +- t/t9805-git-p4-skip-submit-edit.sh | 2 +- t/t9820-git-p4-editor-handling.sh | 2 +- 3

Re: [PATCH] git-p4: Use -m when running p4 changes

On 15/04/15 04:47, Lex Spoon wrote: From 9cc607667a20317c837afd90d50c078da659b72f Mon Sep 17 00:00:00 2001 From: Lex Spoon l...@lexspoon.org Date: Sat, 11 Apr 2015 10:01:15 -0400 Subject: [PATCH] git-p4: Use -m when running p4 changes This patch didn't want to apply for me, I'm not quite sure

[PATCH v2 3/3] git-p4: fix filetype detection on files opened exclusively

/file.png#1 - add default change (binary+l) *exclusive* Signed-off-by: Blair Holloway blair_hollo...@playstation.sony.com Acked-by: Luke Diamand l...@diamand.org Signed-off-by: Luke Diamand l...@diamand.org --- git-p4.py| 2 +- t/t9816-git-p4-locked.sh | 4 ++-- 2 files changed, 3

[PATCH v2 2/3] git-p4: small fix for locked-file-move-test

crashes. At present, git-p4 has no support for detecting that a file has been locked and reporting it to the user, so this is the expected outcome. Signed-off-by: Luke Diamand l...@diamand.org --- t/t9816-git-p4-locked.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t

[PATCH v2 1/3] git-p4: fix small bug in locked test scripts

-by: Luke Diamand l...@diamand.org --- t/t9816-git-p4-locked.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t9816-git-p4-locked.sh b/t/t9816-git-p4-locked.sh index e71e543..ce0eb22 100755 --- a/t/t9816-git-p4-locked.sh +++ b/t/t9816-git-p4-locked.sh @@ -41,7 +41,7

[PATCH v2 0/3] git-p4: updated locked file handling patch series

filetype detection on files opened exclusively Luke Diamand (2): git-p4: fix small bug in locked test scripts git-p4: small fix for locked-file-move-test git-p4.py| 2 +- t/t9816-git-p4-locked.sh | 10 +- 2 files changed, 6 insertions(+), 6 deletions(-) -- 2.3.4.48

Re: [PATCH 0/2] git-p4: Improve client path detection

On 28/03/15 12:28, Vitor Antunes wrote: I'm adding a test case for a scenario I was confronted with when using branch detection and a client view specification. It is possible that the implemented fix may not cover all possible scenarios, but there is no regression in the available tests.

Re: [PATCHv3 1/3] git-p4: add failing test for P4EDITOR handling

On 20/05/15 21:56, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Luke Diamand l...@diamand.org writes: + +test_expect_failure 'EDITOR has options' ' +# Check that the P4EDITOR argument can be given command-line +# options, which git-p4 will then pass through to the shell

Re: [PATCHv1 3/3] git-p4: fixing --changes-block-size handling

On 07/06/15 17:33, Lex Spoon wrote: The implementation looks fine, especially given the test cases that back it up. I am only curious why the block size is set to a default of None. To put it as contcretely as possible: is there any expected configuration where None would work but 500 would not?

Re: [PATCHv1 0/3] git-p4: fixing --changes-block-size support

On 07/06/15 17:01, Lex Spoon wrote: Great work. Thanks! I actually found the problem in my day job, so it was very handy having all the infrastructure already in place! For curiosity's sake, the -m solution has been observed to work on at least one Perforce installation. However clearly it

[PATCHv1 2/3] git-p4: test with limited p4 server results

to work around this. Signed-off-by: Luke Diamand l...@diamand.org --- t/t9818-git-p4-block.sh | 29 +++-- 1 file changed, 23 insertions(+), 6 deletions(-) diff --git a/t/t9818-git-p4-block.sh b/t/t9818-git-p4-block.sh index 79765a4..aae1121 100755 --- a/t/t9818-git-p4-block.sh

[PATCHv1 3/3] git-p4: fixing --changes-block-size handling

-by: Luke Diamand l...@diamand.org --- git-p4.py | 48 +++- t/t9818-git-p4-block.sh | 12 ++-- 2 files changed, 41 insertions(+), 19 deletions(-) diff --git a/git-p4.py b/git-p4.py index 26ad4bc..0e29b75 100755 --- a/git-p4.py +++ b

[PATCHv1 1/3] git-p4: additional testing of --changes-block-size

Add additional tests of some corner-cases of the --changes-block-size git-p4 parameter. Also reduce the number of p4 changes created during the tests, so that they complete faster. Signed-off-by: Luke Diamand l...@diamand.org --- t/t9818-git-p4-block.sh | 56

[PATCHv1 0/3] git-p4: fixing --changes-block-size support

to be uncovered; I find the way that these limits interact somewhat tricky to understand. Thanks, Luke Luke Diamand (3): git-p4: additional testing of --changes-block-size git-p4: test with limited p4 server results git-p4: fixing --changes-block-size handling git-p4.py | 48

[PATCHv3 1/4] git-p4: additional testing of --changes-block-size

Add additional tests of some corner-cases of the --changes-block-size git-p4 parameter. Also reduce the number of p4 changes created during the tests, so that they complete faster. Signed-off-by: Luke Diamand l...@diamand.org Acked-by: Lex Spoon l...@lexspoon.org --- t/t9818-git-p4-block.sh

[PATCHv3 0/4] git-p4: fixing --changes-block-size handling

to find a range that works?) and then take the lowest revision supplied. But that's quite a bit more complex. Luke Diamand (4): git-p4: additional testing of --changes-block-size git-p4: test with limited p4 server results git-p4: add tests for non-numeric revision range git-p4: fixing

[PATCHv3 3/4] git-p4: add tests for non-numeric revision range

Test that git-p4 can handle a sync with a non-numeric revision range (e.g. a date). Signed-off-by: Luke Diamand l...@diamand.org --- t/t9800-git-p4-basic.sh | 38 ++ 1 file changed, 38 insertions(+) diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4

[PATCHv3 4/4] git-p4: fixing --changes-block-size handling

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 l...@diamand.org --- git-p4.py | 85 - t/t9818-git-p4-block.sh | 12

[PATCHv3 2/4] git-p4: test with limited p4 server results

to work around this. Signed-off-by: Luke Diamand l...@diamand.org Acked-by: Lex Spoon l...@lexspoon.org --- t/t9818-git-p4-block.sh | 29 +++-- 1 file changed, 23 insertions(+), 6 deletions(-) diff --git a/t/t9818-git-p4-block.sh b/t/t9818-git-p4-block.sh index 79765a4..aae1121

[PATCHv2 2/3] git-p4: test with limited p4 server results

to work around this. Signed-off-by: Luke Diamand l...@diamand.org Acked-by: Lex Spoon l...@lexspoon.org --- t/t9818-git-p4-block.sh | 29 +++-- 1 file changed, 23 insertions(+), 6 deletions(-) diff --git a/t/t9818-git-p4-block.sh b/t/t9818-git-p4-block.sh index 79765a4..aae1121

[PATCHv2 1/3] git-p4: additional testing of --changes-block-size

Add additional tests of some corner-cases of the --changes-block-size git-p4 parameter. Also reduce the number of p4 changes created during the tests, so that they complete faster. Signed-off-by: Luke Diamand l...@diamand.org Acked-by: Lex Spoon l...@lexspoon.org --- t/t9818-git-p4-block.sh

[PATCHv2 0/3] git-p4: fixing --changes-block-size handling

and hasn't been broken by these changes. Luke Luke Diamand (3): git-p4: additional testing of --changes-block-size git-p4: test with limited p4 server results git-p4: fixing --changes-block-size handling git-p4.py | 45 ++ t/t9818-git-p4-block.sh

[PATCHv2 3/3] git-p4: fixing --changes-block-size handling

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 l...@diamand.org --- git-p4.py | 45 - t/t9818-git-p4-block.sh | 12

Re: Dependency Management

On 23/06/15 19:49, Josh Hagins wrote: If neither git-submodule nor git-subtree is palatable to you, here are a couple of alternatives you might try: * https://github.com/ingydotnet/git-subrepo * https://github.com/tdd/git-stree You could also use Android's repo tool:

Re: BUG: checkout won't checkout?

On 18 June 2015 at 23:28, Junio C Hamano gits...@pobox.com wrote: Luke Diamand l...@diamand.org writes: This is probably user error, but I'm not sure what I'm doing wrong. I'm posting here in case anyone else gets the same thing I'm using 2.4.4.598.gd7bed1d, i.e. 'next' as of today. I've

Re: BUG: checkout won't checkout?

On 18 June 2015 at 23:53, Junio C Hamano gits...@pobox.com wrote: Luke Diamand l...@diamand.org writes: $ git checkout upstream/master -- subtree $ git diff upstream/master -- subtree -- still lots of deltas Does this show _ONLY_ additions? Or does it include modifications and removals

BUG: checkout won't checkout?

This is probably user error, but I'm not sure what I'm doing wrong. I'm posting here in case anyone else gets the same thing I'm using 2.4.4.598.gd7bed1d, i.e. 'next' as of today. I've somehow ended up with history skipping back in time, but git not prepared to let let me fix it, or something.

Re: BUG: checkout won't checkout?

The other thing about these files is that they were all deleted a few weeks ago and have now come back. On 18 June 2015 at 23:07, Luke Diamand l...@diamand.org wrote: This is probably user error, but I'm not sure what I'm doing wrong. I'm posting here in case anyone else gets the same thing

Re: format-patch and submodules

On 10/06/15 18:04, Christopher Dunn wrote: Sorry. I thought empty patches were made to work in other cases. 'git-p4' needs to skip these. Wrong mailing list then. Possibly the right mailing list - can you explain what you mean here w.r.t git-p4 please? Thanks! Luke On Tue, Jun 9,

Re: [PATCH] p4: Retrieve the right revision of the UTF-16 file

On 27/05/15 23:31, Miguel Torroja wrote: Fixing bug with UTF-16 files when they are retreived by git-p4. It was always getting the tip version of the file and the history of the file was lost. This looks sensible to me, and seems to work in some simple testing, thanks! Ack. Luke ---

Re: [git-p4] import with labels fails when commit is not transferred

Sorry for not replying earlier, and thanks for taking the time to investigate this! It's a pretty subtle corner case: I think a test case would be useful. I'm going to try to put something together, unless you beat me to it! (I think t9811-git-p4-label-import.sh is the one that needs

Re: [PATCH 2/2] git-p4: fix handling of multi-word P4EDITOR

On 07/05/15 23:16, Junio C Hamano wrote: Luke Diamand l...@diamand.org writes: [Resurrecting old thread] Looking at run-command.c, GIT_WINDOES_NATIVE and POSIX seems to use pretty much the same construct, except that they use SHELL_PATH instead of sh. I think the state of git on Windows

Re: What's cooking in git.git (May 2015, #06; Fri, 22)

On 22/05/15 23:14, 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'. ry_matches(): inline function + is_ The fourth batch of topics have been merged to 'master'.

Re: git p4 clone - exclude file types

A quick test just cloning a repo with 4 files of 256MB each seems fine, FWIW. It is also on the same physical network as the Perforce server. I remember seeing someone else complain about this, but I can't find the article/blog now. On Wed, May 20, 2015 at 12:49 AM, Luke Diamand l...@diamand.org

Re: [PATCH v4] git-p4: fix faulty paths for case insensitive systems

Lars - thanks for persisting with this! I'm still trying to fully understand what's going on here - can you point out where I've got it wrong below please! The server is on Linux, and is case-sensitive. For whatever reason (probably people committing changes on Windows in the first place) we've

Re: [PATCH v4] git-p4: fix faulty paths for case insensitive systems

On 24 August 2015 at 13:43, Lars Schneider larsxschnei...@gmail.com wrote: https://github.com/luked99/quick-git-p4-case-folding-test As mentioned I realized that the problem occurs only if you use client specs. Can you take a look at this test case / run it?

Re: [PATCH v4] git-p4: fix faulty paths for case insensitive systems

On 24 August 2015 at 10:51, Lars Schneider larsxschnei...@gmail.com wrote: I'm still trying to fully understand what's going on here - can you point out where I've got it wrong below please! Your welcome + sure :) snip While I was working on the examples for this email reply I realized

Re: [git-p4] import with labels fails when commit is not transferred

On 04/07/15 04:27, Luke Diamand wrote: Sorry for not replying earlier, and thanks for taking the time to investigate this! It's a pretty subtle corner case: I think a test case would be useful. I'm going to try to put something together, unless you beat me to it! (I think t9811-git-p4-label

Re: [PATCH] git-p4: fix faulty paths for case insensitive systems

On 02/08/15 16:15, larsxschnei...@gmail.com wrote: From: Lars Schneider larsxschnei...@gmail.com Hi, I want to propose this patch as it helped us to migrate a big source code base successfully from P4 to Git. I am sorry that I don't provide a test case, yet. Case sensitivity is a pretty

Re: [PATCH v1] git-p4: Add option to ignore empty commits

On 24/10/15 17:28, Lars Schneider wrote: Also I have this suspicion that those who do want to use client spec to get a narrowed view into the history would almost always want this "ignore empty" behaviour (I'd even say the current behaviour to leave empty commits by default is a bug). What

Re: [PATCH v1 0/2] git-p4: Fix tests on OS X

On 12/10/15 18:03, larsxschnei...@gmail.com wrote: From: Lars Schneider I extracted this patch series from "[PATCH v3 0/3] Add Travis CI support" as suggested by Junio. All seems sensible to me. Luke Thanks, Lars Lars Schneider (2): git-p4: Improve test

Re: [PATCH v1] git-p4: Add option to ignore empty commits

On 24/10/15 19:08, Lars Schneider wrote: On 21 Oct 2015, at 08:32, Luke Diamand <l...@diamand.org> wrote: On 19/10/15 19:43, larsxschnei...@gmail.com wrote: From: Lars Schneider <larsxschnei...@gmail.com> This seems to be adding a new function in the middle of an exist

Re: [PATCHv1 2/2] git-p4: work with a detached head

On 28/10/15 17:44, Junio C Hamano wrote: Luke Diamand <l...@diamand.org> writes: On 9 September 2015 at 22:52, Junio C Hamano <gits...@pobox.com> wrote: Luke Diamand <l...@diamand.org> writes: ... def currentGitBranch(): return read_pipe("git name-rev HEA

Re: [PATCH v5 3/6] git-p4: retry kill/cleanup operations in tests with timeout

On 15/11/15 13:08, larsxschnei...@gmail.com wrote: From: Lars Schneider In rare cases kill/cleanup operations in tests fail. Retry these operations with a timeout to make the test less flaky. Should there be a sleep in that retry_until_success loop so that it

  1   2   3   4   >