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
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
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
---
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
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'.
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
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
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
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
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
(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
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
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
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
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
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
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
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
.
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
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
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
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
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
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
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
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
...@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
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
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
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
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
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
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.
/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
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
-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
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
/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
-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
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
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
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
(+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
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
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
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
(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
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
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
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
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
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
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
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
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,
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
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
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?
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
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
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
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
+++
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)
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
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
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
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
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
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
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,
301 - 370 of 370 matches
Mail list logo
