Prevent the following warning in the web server error log:
gitweb.cgi: Odd number of elements in anonymous hash at
/usr/share/gitweb/gitweb.cgi line 3305
---
gitweb/gitweb.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 2594a4
uot;[ttk::style theme use]" was added to ttext in 30508bc
("Amend tab ordering and text widget border and highlighting.",
2016-10-02). Break out InitTheme's workaround into its own
get_current_theme proc and use it in both places.
Signed-off-by: Pete Harlan
---
Note: Applies
s/branchortag
tagonly
Previous behavior:
% git tag
branchortag
tagonly
I prefer the previous behavior. Perhaps the change was intentional,
but I didn't see it documented.
Thanks,
Pete Harlan
p...@tento.net
--
To unsubscribe from this list: send the line "unsubscribe git"
> >>stat --format=%A text+x | egrep ^-r-x
> >>fi
> >
> > Not a new problem but why do we need "stat" here?
> >
> > Shouldn't "test -r", "! test -x", and their usual friends be
> > suffi
sitively in the string, which led to false positives when
Perhaps s/case-insensitively/anywhere/?
It's not important that it ignored case (your change ignores it too),
it's that it was too lenient about its context.
--Pete
> GIT_SSH contained "uplink". Improve the check by
.e., like the output of `git diff`). If `-v` is specified
Should this be `git diff --cached`?
> > + twice, then also show the changes in the working tree that
> > + have not yet been staged (i.e., like the output of `git diff
> > + --cached`).
...and should this just be `git diff`?
-
ubstantive work to git-p4 in the near future.
Luke: I think you have a couple patches outstanding; hope these
can get merged to mainline soon.
Thanks,
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.
y" \
> +print "or \"p4 submit -i <%s\" to use the one prepared by" \
>" \"git p4\"." % fileName
> print "You can delete the file \"%s\" when finished." % fileName
>
Looks
er than git :-(
So sorry. I on the other hand have been fortunate enough to
switch to using only git.
Nevertheless, I read through the patch and it looks good and
makes sense. You've got my ack on this for what it's worth.
Hopefully someone else starts picking up the git-p4 maintenanc
-OPTIONS
> +
> ifndef NO_PYTHON
> $(SCRIPT_PYTHON_GEN): GIT-CFLAGS GIT-PREFIX GIT-PYTHON-VARS
> $(SCRIPT_PYTHON_GEN): % : %.py
> --
> 2.1.0.rc2.206.gedb03e5
Looks obviously correct, thanks for remembering the other
scripting languages. :)
Acked-by: Pete Wyckoff
--
To unsub
these not so flaky, but your change here fixes a problem, and
doesn't do any harm. And gives you an opportunity to fix it more
later. :)
Be sure to fix the word-wrapping you have on two of the lines
below. And be careful not to top post.
Here's my ack for when you decide to send it back t
port stream,
which is supposed to make it write the branches out. You might
consider grabbing the fast-import process in a debugger and see
why it's not writing out the branch head.
There's lots of changes since v1.7.12.4, but nothing obvious I
can see that would cause this. Sorry,
revision of each
file for each change already in git. And git already knows the
blob for each of files in those changes. With this mapping, you
could modify git p4 to check for the blob first, before doing "p4
print" on the file#rev. See also git-p4raw from Sam Vilain that
builds up SQL f
ple comparisons like
you quote.
I'm not sure how to robustify this. At least doing the multiple
comparisons should make the tests work again. The goal of this
series of tests is to make sure that copy detection is working,
not to verify that the correct copy choice was made. That should
b
frrr...@gmail.com wrote on Wed, 11 Jun 2014 14:06 +0100:
> On Tue, Jun 10, 2014 at 06:39:58PM -0400, Pete Wyckoff wrote:
> > frrr...@gmail.com wrote on Tue, 10 Jun 2014 13:14 +0100:
> > > b4073bb387ef303c9ac3c044f46d6a8ae6e190f0 broke git p4 submit, here
> > > is a p
put into a maintenance release, quickly?
The fix looks good. It's surprising that none of the tests
managed to add a file and trigger the failure.
I'll ack this again, as it looks okay, but hope you ran all the
unit tests successfully on your machine.
-- Pete
> Sig
existing 9807 is fine. Unless of course you
have one ready to go.
Acked-by: Pete Wyckoff
You might add my ack and send it directly to Junio + CC the list.
It'll be a nice improvement for the next available release.
-- Pete
--
To unsubscribe from this list: send the line &qu
eers,
> >Tolga
>
> Any feedback is appreciated.
Sorry, travel delay. This explanation is pretty
straight-forward, thanks.
Suggest you include it in the commit message along with the
other text you had, and resend to the list, cc me and junio.
Oh, and include an ack:
Acked
apply "
> tryPatchCmd = patchcmd + "--check -"
> applyPatchCmd = patchcmd + "--check --apply -"
> --
This looks like a straightforward change, but can you give a
bit more background on why a full index is required? Do you
mean that "git apply&
ect-branches -v
Yes, this is a good bug. You could do "git rev-parse -q --verify"
on parent before trying to read the rev-list.
But then what should happen? I suspect git-p4 will just create
that ref when it commits the change it is considering.
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ul text.
2. Include at the bottom of that message:
Acked-by: Pete Wyckoff
3. Inline the text of your patch, not just a link to github.
4. Consider adding a t98xx test. This isn't required for
a fairly minor change like yours, but if you think TDD
is
' to separate paths from revisions, like this:
> 'git [...] -- [...]'
>
> Take the suggestion above and explicitly state that HEAD should be
> treated as a revision.
>
> Signed-off-by: Vlad Dogaru
This looks obviously good to me, thanks!
Junio, could you car
could get something like this to work.
Start in getBranchMapping() and don't forget to write up your
work in Documentation/git-p4.txt. Also, this is sort of a messy
area of the code, unfortunately. t/t9801 tries to make sure some
of it keeps working.
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signed-off-by: Pete Wyckoff
---
Documentation/git-p4.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 8cba16d..6ab5f94 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -168,7 +168,8 @@ All
When "p4 where" fails, for whatever reason, the error message tries to
show an undefined variable. This minor bug applies only when using a
client spec, and was introduced recently in 9d57c4a (git p4: implement
view spec wildcards with "p4 where", 2013-08-30).
Signed-
fixes appear in the future.
Signed-off-by: Pete Wyckoff
---
t/t9816-git-p4-locked.sh | 145 +++
1 file changed, 145 insertions(+)
create mode 100755 t/t9816-git-p4-locked.sh
diff --git a/t/t9816-git-p4-locked.sh b/t/t9816-git-p4-locked.sh
new file
y calling wildcard_encode() on the raw
filename.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 4 ++--
t/t9812-git-p4-wildcards.sh | 23 +++
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index f0a327d..39a0fa0 100755
-
ec the args
directly, without shell expansion.
Second, without shell expansion, the trick of "P4EDITOR=:" used
in the tests doesn't work. Use a real command, true, as the
non-interactive editor for testing.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 2 +-
t/l
Commit e9df0f9 (git p4: cygwin p4 client does not mark read-only,
2013-01-26) fixed a problem with "test -w" on cygwin, but mistakenly
marked the new test as failing. Fix this.
Signed-off-by: Pete Wyckoff
---
t/t9807-git-p4-submit.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletio
duced in 848de9c (git-p4: warn if
git authorship won't be retained, 2011-05-13).
Fix t9813 to use @example.com instead of @localhost due to change
in p4_add_user(). Move the function into the git p4 test library
so author can be added at initialization time.
Signed-off-by: Pete Wyckoff
---
roduced by 1292df1 (git-p4:
Fix occasional truncation of symlink contents., 2013-08-08) and
appeared first in 1.8.5. But it shows up only in p4
repositories of dubious character, so can wait for a proper
release.
Tested-by: Damien Gérard
Signed-off-by: Pete Wyckoff
---
git-p4.py
While this happens to work, there was no test to make sure
that the basic importing of a symlink from p4 to git functioned.
Add a simple test to create a symlink in p4 and import it into git,
then verify that the symlink exists and has the correct target.
Signed-off-by: Pete Wyckoff
---
t
There was no test where p4 deleted a file with a wildcard
character. Make sure git p4 applies the wildcard decoding
properly when importing a delete that includes a wildcard.
Signed-off-by: Pete Wyckoff
---
t/t9812-git-p4-wildcards.sh | 27 +++
1 file changed, 27
Since 9d57c4a (git p4: implement view spec wildcards with "p4
where", 2013-08-30), all the wildcard types should be supported.
Change must-fail tests to mark that they now pass.
Signed-off-by: Pete Wyckoff
---
t/t9809-git-p4-client-view.sh | 16
1 file changed, 8
gits...@pobox.com wrote on Tue, 21 Jan 2014 16:03 -0800:
> Pete Wyckoff writes:
[..]
> > Patch 03 is a regression fix, found and narrowed down thanks to
> > much work by Damien Gérard. But it is obscure enough that I'm
> > not proposing it for a maintenance relea
Signed-off-by: Pete Wyckoff
---
Documentation/git-p4.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 8cba16d..6ab5f94 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -168,7 +168,8 @@ All
fixes appear in the future.
Signed-off-by: Pete Wyckoff
---
t/t9816-git-p4-locked.sh | 145 +++
1 file changed, 145 insertions(+)
create mode 100755 t/t9816-git-p4-locked.sh
diff --git a/t/t9816-git-p4-locked.sh b/t/t9816-git-p4-locked.sh
new file
When "p4 where" fails, for whatever reason, the error message tries to
show an undefined variable. This minor bug applies only when using a
client spec, and was introduced recently in 9d57c4a (git p4: implement
view spec wildcards with "p4 where", 2013-08-30).
Signed-
y calling wildcard_encode() on the raw
filename.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 4 ++--
t/t9812-git-p4-wildcards.sh | 23 +++
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index a4414b5..26b874f 100755
-
Commit e9df0f9 (git p4: cygwin p4 client does not mark read-only,
2013-01-26) fixed a problem with "test -w" on cygwin, but mistakenly
marked the new test as failing. Fix this.
Signed-off-by: Pete Wyckoff
---
t/t9807-git-p4-submit.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletio
ec the args
directly, without shell expansion.
Second, without shell expansion, the trick of "P4EDITOR=:" used
in the tests doesn't work. Use a real command, true, as the
non-interactive editor for testing.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 2 +-
t/l
s was
introduced in 848de9c (git-p4: warn if git authorship won't
be retained, 2011-05-13).
Fix t9813 to use @example.com instead of @localhost due to
change in p4_add_user(). Move the function into the git p4
test library so author can be added at initialization time.
Signed-off-by: Pete Wyckoff
roduced by 1292df1 (git-p4:
Fix occasional truncation of symlink contents., 2013-08-08) and
appeared first in 1.8.5. But it only shows up only in p4
repositories of dubious character, so can wait for a proper
release.
Tested-by: Damien Gérard
Signed-off-by: Pete Wyckoff
---
git-p4.py
There was no test where p4 deleted a file with a wildcard
character. Make sure git p4 applies the wildcard decoding
properly when importing a delete that includes a wildcard.
Signed-off-by: Pete Wyckoff
---
t/t9812-git-p4-wildcards.sh | 27 +++
1 file changed, 27
While this happens to work, there was no test to make sure
that the basic importing of a symlink from p4 to git functioned.
Add a simple test to create a symlink in p4 and import it into git,
then verify that the symlink exists and has the correct target.
Signed-off-by: Pete Wyckoff
---
t
d can wait for the next release.
Pete Wyckoff (11):
git p4 test: wildcards are supported
git p4 test: ensure p4 symlink parsing works
git p4: work around p4 bug that causes empty symlinks
git p4 test: explicitly check p4 wildcard delete
git p4 test: is_cli_file_writeable succeeds
git p4
Since 9d57c4a (git p4: implement view spec wildcards with "p4
where", 2013-08-30), all the wildcard types should be supported.
Change must-fail tests to mark that they now pass.
Signed-off-by: Pete Wyckoff
---
t/t9809-git-p4-client-view.sh | 16
1 file changed, 8
dam...@iwi.me wrote on Thu, 16 Jan 2014 17:02 +0100:
>
> On 16 Jan 2014, at 15:45, Pete Wyckoff wrote:
>
> > Oh cool, that helps a lot. P4 is just broken here, so we can get
> > away with being a bit sloppy in git. I'll try just pretending
> > "empty syml
dam...@iwi.me wrote on Thu, 16 Jan 2014 14:46 +0100:
>
> On 16 Jan 2014, at 14:08, Pete Wyckoff wrote:
>
> > dam...@iwi.me wrote on Wed, 15 Jan 2014 09:56 +0100:
> >> p4 fstat //depot/openssl/0.9.8j/openssl/include/openssl/bn.h@59702
> >> ... depotFile //dep
dam...@iwi.me wrote on Wed, 15 Jan 2014 09:56 +0100:
> p4 fstat //depot/openssl/0.9.8j/openssl/include/openssl/bn.h@59702
> ... depotFile //depot/openssl/0.9.8j/openssl/include/openssl/bn.h
> ... headAction edit
> ... headType symlink
> ... headTime 1237906419
> ... headRev 2
> ... headChange 597
nk#1 | od -c
>
> Thanks for checking this depot info first.
I've tried to hack a test that produces a null symlink,
and having done so, find an error later on trying to
generate a symlink that points to "". So the "easy"
fix of checking for an empty string is unlikely
nts to nowhere. Maybe do:
$ p4 describe -s 59702
and see if you can figure out which of those could be a symlink, then
inspect it:
$ p4 fstat //depot/symlink@59702
(probably shows it is "headRev 1")
$ p4 print -q //depot/symlink#1
$ p4 print -q //depot/symlink#1 | od -
frrr...@gmail.com wrote on Mon, 13 Jan 2014 12:10 +:
> Hello,
>
> On Sun, Jan 12, 2014 at 05:29:46PM -0500, Pete Wyckoff wrote:
> > Thanks for the patch, but I'm curious how you'd like this to
> > work. I never use the option myself.
> >
> > As i
#x27;t actually feed this file directly to "p4 submit"
without deleting the diff. That's the part you don't like?
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thomas Rast writes:
> Antoine Pelisse writes:
>
>>>> On Wed, 27 Nov 2013 15:17:27 +
>>>> Pete Forman wrote:
>>>>
>>>>> I am looking for a way of detecting up front whether a git pull or
>>>>> git merge woul
pre-merge-okay
that deals with things like benign untracked files.
I have also asked this question on Stack Overflow but received no
answers.
http://stackoverflow.com/questions/20221383/
--
Pete Forman
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of
> Noticed while considering marking the contrib/p4import/git-p4import.py
> script executable as part of a wider sweep.
I haven't seen git-p4import mentioned for the last 6 years either.
Thanks,
Acked-by: Pete Wyckoff
--
To unsubscribe from this list: send the line "
^\"..\"%s\"" % (id, id)
> > +diffcmd = "git diff-tree -p \"%s\"" % (id)
> > patchcmd = diffcmd + " | git apply "
> > tryPatchCmd = patchcmd + "--check -"
> > applyPatchCmd = patchcmd + &q
The changes don't overlap. If you give it a range that includes
changes already synced, git-p4 makes sure to start only at the
lowest change it has not yet seen. I'll see if I can update the
docs somewhere.
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
(3 sec ?). My theory
about one gigantic object is debunked: you have only the 118 MB
one. Perhaps there's some container or process memory limit, as
Luke guessed, but it's not obvious here.
The other big hammer is "strace". If you're still interested in
playing wit
h mail that incorporated your sent one?
> Or nothing to do?
It would be good if you could fold the one I sent in with yours,
and clean up any stylistic issues as you go.
I'll play with it a bit more, then send on to Junio for
the next release.
Thanks, this is a good addition!
fill all of memory. You will at least isolate
the change.
There are options to git-fast-import to limit max pack size
and to cause it to skip importing files that are too big, if
that would help.
You can also use a client spec to hide the offending files
from git.
Can you watch with "
e attractiveness of the simplicity and increased client spec feature
coverage weighs in its favor. Let's go ahead and inflict this on the
world and see what they think.
Do you have an updated patch? Want to take some time to clean up and
resubmit the entire series? The batching should be incorporated with
the last 2/2 that I sent out.
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
perf tests on the 3-patch version. It
looks good. You should expect a reroll of the 2nd and 3rd
commits, combining them into one patch.
Thanks for tracking these.
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to major
; to just search cache value.
>
> Could you accept?
This looks good. I've started my own performance testing
on a few-hundred-thousand file repo to confirm your findings.
If it seems to work out, we can clean up the patch. Otherwise
maybe need to think about having both implementatio
al...@rosedu.org wrote on Mon, 12 Aug 2013 10:46 +0300:
> On 11 August 2013 14:57, Pete Wyckoff wrote:
> > al...@rosedu.org wrote on Thu, 08 Aug 2013 16:17 +0300:
> >> Symlink contents in p4 print sometimes have a trailing
> >> new line character, but sometimes it doesn
\0 \0 c o d e s 006 \0 \0 \0 b i n a r
360 y s 004 \0 \0 \0 d a t a s \0 \0 \0 \0 0
400
Also, what version is your server, from "p4 info":
Server version: P4D/LINUX26X86_64/2013.1/610569 (2013/03/19)
--
[pw: use unset, add commit text]
Signed-off-by: Kazuki Saitoh
Signed-off-by: Pete Wyckoff
---
t/lib-git-p4.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
index 2098b9b..ccd918e 100644
--- a/t/lib-git-p4.sh
+++ b/t/lib-git-p4.sh
@@ -4
rns out to be a problem,
we might consider resurrecting the old wildcard code just
for use on the "easy" cases it understands.
[pw: redo code and tests]
Signed-off-by: Kazuki Saitoh
Signed-off-by: Pete Wyckoff
---
git-p4.py | 204 +--
ern is in the commit message, about performance. A
change that has lots of files in it will cause many roundtrips to
p4d to do "p4 where" on each. When the files don't have much
edited content, this new approach will make the import take twice
as long, I'll guess. Do you have a
d cleanup_git &&
How does the p4 sync help here?
> +test_expect_success 'view wildcard *' '
> + client_view "//depot/... //client/..." \
> + "-//depot/dir1/*.junk //client/dir1/*.junk" \
> + "-//depot/dir2/*.junk //client/dir2/*.junk&quo
on with Matthieu that we
did indeed have tests for detect-branches with use-client-spec.
This test sure seems like it should cover that situation though.
Acked-by: Pete Wyckoff
> ---
> t/t9801-git-p4-branch.sh | 23 ---
> 1 file changed, 20 insertions(+), 3 deletio
27;m a bit out of my depth on case-insensitive file systems. Do
check if the cloner in question has core.ignorecase config option
set:
git config --get core.ignorecase
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
+
> > The default is "master".
> >
> > The rest of the patch looks good.
>
> Myy reading did hiccup at the same "remote-tracking" used as if it
> were a noun, and your rewritten version reads much better.
Yes, very clear and complete rewrite;
s by explicitly
> naming the upstream branch to base the new local branch on when
> calling 'git checkout'.
Thanks for finding and fixing this. Great explanation. I
tested it locally too.
Acked-by: Pete Wyckoff
-- Pete
--
To unsubscribe from this list: send the li
e interesting
if this turns out to be your problem too. Maybe we could look
for that and do something sensible.
The other thing to check is "p4 client -o" and see what LineEnd
setting exists for the backing p4 workspace.
-- Pete
> From aef963f0c45dea81f3e6f30d3b4185
0m3.212s
64 real 0m3.173s
COLD
1 real 1m36.969s
2 real 0m51.627s
4 real 0m32.994s
8 real 0m25.657s
16 real 0m21.260s
32 real 0m18.138s
64 real 0m17.265s
I am tempted to change the default locally from 8 to 32.
-- Pete
--
To unsubscribe from this list: send the line "uns
dav...@gmail.com wrote on Sat, 20 Apr 2013 03:50 -0700:
> On Thu, Apr 18, 2013 at 5:09 PM, Pete Wyckoff wrote:
> >> First issue
> >> ---
> >>
> >> git-p4 assumes the output of 'p4 print' adds a newline to the
> >> target.
gt; lrwxrwxrwx 1 atomlinson atomlinson 12 Apr 18 20:25 ./xxx -> ../libs/pcre/
Me too. That's annoying behavior, but not used by git-p4 fortunately.
The "-o -" option is only used for odd utf16 files where "p4 print"
generates invalid output.
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
enSSL 1.0.1c 10 May 2012
> Rev. P4/LINUX26X86_64/2013.1/610569 (2013/03/19).
This code only happens on utf16 files. But running it by hand,
I cannot reproduce the different behavior:
$ p4 print -q //depot/f-ascii
three
line
text
$ p4 print -o - -q //depot/f-ascii
three
line
$ ls ./-
ls: cannot access ./-: No such file or directory
I'm again confused. Any hints you can give would be helpful.
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
same line-ending conventions
in both git and p4 land. This is easy if they are both lf. But,
if crlf is preferred, do you know how to configure git to use
crlf line endings? Does that fix it? There's also the config
setting "apply.ignorewhitespace"; not sure if that would al
a CRLF line ending problem on Windows.
I had recently debugged a similar-looking problem
where core.autocrlf was set to "input".
Christopher, if you have this set and/or the .xml files
have ^M (CRLF) line endings, please let us know.
-- Pete
>
> On Thu, Apr 11,
of it, but there are more
issues as well. I'll address them once you've taken care of the
opened/fstat issue. Thanks,
-- Pete
--- 8< ---
>From c6691126ae75c364763ab4d774c75045285b8ddd Mon Sep 17 00:00:00 2001
From: Pete Wyckoff
Date: Sun, 17 Mar 2013 16:05:07 -
ion. Do you want to
reroll your patch to use fstat? I'll work on the tests, and
also look into potential failure modes of "git p4 submit" when somebody
else has the exclusive file open.
-- Pete
> On 17/03/2013 20:04, "Pete Wyckoff" wrote:
>
>
f your p4d includes " *exclusive*" in the
type there too, in which case we'll have to strip it.
Thanks for starting the patch on this. It's good if we can keep
others from running into the same problem.
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
that and that directories, but the
> consumers should check other directories themselves."
fanotify is an option here too; it can watch an entire file
system.
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messag
]
Thanks-to: John Keeping
Signed-off-by: Pete Wyckoff
---
git-p4.py | 29 ++---
t/t9808-git-p4-chdir.sh | 2 +-
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 647f110..7288c0b 100755
--- a/git-p4.py
+++ b/git-p4.py
This test fails when the p4 client root includes
a symlink. It complains:
Path /vol/bar/projects/foo/... is not under client root /p/foo
and dumps a traceback.
Signed-off-by: Pete Wyckoff
---
t/t9808-git-p4-chdir.sh | 27 +++
1 file changed, 27 insertions(+)
diff
; it builds a path by prepending
the contents of the PWD environment variable.
Signed-off-by: Pete Wyckoff
---
t/t9808-git-p4-chdir.sh | 14 ++
1 file changed, 14 insertions(+)
diff --git a/t/t9808-git-p4-chdir.sh b/t/t9808-git-p4-chdir.sh
index dc92e60..55c5e36 100755
--- a/t/t9808-git
4: use absolute
directory for PWD env var, 2011-12-09), but that's so long ago
that I don't think this is a candidate for maint.
-- Pete
Miklós Fazekas (1):
git p4: avoid expanding client paths in chdir
Pete Wyckoff (2):
git p4 test: make sure P4CONFIG relative path works
]
Thanks-to: John Keeping
Signed-off-by: Pete Wyckoff
---
git-p4.py | 29 ++---
t/t9808-git-p4-chdir.sh | 2 +-
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 647f110..7288c0b 100755
--- a/git-p4.py
+++ b/git-p4.py
This test fails when the p4 client root includes
a symlink. It complains:
Path /vol/bar/projects/foo/... is not under client root /p/foo
and dumps a traceback.
Signed-off-by: Pete Wyckoff
---
t/t9808-git-p4-chdir.sh | 27 +++
1 file changed, 27 insertions(+)
diff
; it builds a path by prepending
the contents of the PWD environment variable.
Signed-off-by: Pete Wyckoff
---
t/t9808-git-p4-chdir.sh | 14 ++
1 file changed, 14 insertions(+)
diff --git a/t/t9808-git-p4-chdir.sh b/t/t9808-git-p4-chdir.sh
index dc92e60..55c5e36 100755
--- a/t/t9808-git
on't think this is a candidate for maint.
-- Pete
Miklós Fazekas (1):
git p4: avoid expanding client paths in chdir
Pete Wyckoff (2):
git p4 test: make sure P4CONFIG relative path works
git p4 test: should honor symlink in p4 client root
git-p4.py | 29 +++
regular fast-imports
Here's one thread:
http://thread.gmane.org/gmane.comp.version-control.git/179231/focus=179292
I've got a patch in cold storage. It's not beautiful because
there are too many paths that can end up hitting EMFILE. I'll
dust it off and see if it is wor
gits...@pobox.com wrote on Fri, 22 Feb 2013 16:42 -0800:
> Olivier Delalleau writes:
>
> > 2013/1/5 Pete Wyckoff :
> >> sh...@keba.be wrote on Thu, 03 Jan 2013 15:58 -0500:
> > ...
> >> Please do feel welcome to to rearrange or expand the
> >> docume
pclo...@gmail.com wrote on Sun, 17 Feb 2013 11:39 +0700:
> On Sun, Feb 17, 2013 at 1:11 AM, Pete Wyckoff wrote:
> > pclo...@gmail.com wrote on Sat, 16 Feb 2013 14:17 +0700:
> >> Finally some numbers (best of 20 runs) that shows why it's worth all
> >> the hassle:
Duy min 2.04 avg 3.12 +/- 0.69 max 4.87
libreoffice-core
Stock min 4.56 avg 5.79 +/- 0.79 max 7.08
Duy min 3.96 avg 5.25 +/- 0.95 max 6.95
Similar 30%-ish speedup on webkit. And an absolute gain
of 2.7 seconds is quite nice.
-- Pete
--
To unsubscribe from this li
it would be better to
separate the callers of chdir(): those that know they are
cd-ing to a path from a p4 client, and everybody else. The former
should not use os.getcwd(), as you show.
I'll whip something up soon, unless you beat me to it.
-- Pete
--
To unsubscribe fr
rself to some subset of the library
> rather than just not using it.
>
> In fact, git_remote_helpers has been available since Git 1.7.0 and
> contains a lot of functionality that is more generic than its name
> suggests.
This library idea would be a great help; there are 100-odd calls
to git in git-p4, and we've had to deal with getting the arguments
and parsing correct. I'd happily switch to using git_core.
Probably some elements of GitPython can be used too. I'm not so
interested in the raw database manipulation, but the command
wrappers look reasonable.
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
1 - 100 of 246 matches
Mail list logo
