Hi !
I hope this is the right mailing list for question regarding the usage
of git-p4, sorry if I'm wrong.
Here is my problem: I'm issuing the command
'git p4 clone //kalma/xxx/yyy@all'. (the depot //kalma/xxx/yyy/ exists
on my machine and is full of files). After this command the directory
'yyy' is created and the history of commits is visible there by 'git log
-p'.
Every commit contains author name, a title (related to the project I'm
working on, so obviously coming from perforce depot) and a single line
looking like this:
[git-p4: depot-paths = "//kalma/xxx/yyy/": change = 17473]
Beside of that, the commit is empty: not a single line of code is
changed/added. And the directory 'yyy' contains only the '.git'
subdirectory, so not a single file of the project is visible.
Please help me to understand what could be going on there, and what
could I have done wrong.
Thanks a lot!
-- Ilya Dogolazky
From: Luke Diamand <hidden> Date: 2016-06-15 22:54:02
On Mon, Jun 11, 2012 at 11:03 AM, Ilya Dogolazky
[off-list ref] wrote:
Hi !
I hope this is the right mailing list for question regarding the usage of
git-p4, sorry if I'm wrong.
This is the right place!
Here is my problem: I'm issuing the command
'git p4 clone //kalma/xxx/yyy@all'. (the depot //kalma/xxx/yyy/ exists on my
machine and is full of files). After this command the directory 'yyy' is
created and the history of commits is visible there by 'git log -p'.
Every commit contains author name, a title (related to the project I'm
working on, so obviously coming from perforce depot) and a single line
looking like this:
[git-p4: depot-paths = "//kalma/xxx/yyy/": change = 17473]
Beside of that, the commit is empty: not a single line of code is
changed/added. And the directory 'yyy' contains only the '.git'
subdirectory, so not a single file of the project is visible.
Please help me to understand what could be going on there, and what could I
have done wrong.
If you do something like "p4 describe 17473" what does that show?
Are the files changed all contained with //kalma/xxx/yyy?
It could be that there's a p4 version problem going on - which version
of p4 are you
using? And which platform are you using?
Thanks,
Luke
Hi Luke!
06/11/2012 06:28 PM, ext Luke Diamand написал:
If you do something like "p4 describe 17473" what does that show?
First I see a line containing the change number, my colleague's name and
date, then the commit title (identical to one printed by "git log"),
then a list of files [every line begins with "... //xxx/yyy/"], then the
word "Differences" and then something looking very much like output of
'diff' command (the actual commit differences).
Are the files changed all contained with //kalma/xxx/yyy?
Yes, they are.
It could be that there's a p4 version problem going on - which version
of p4 are you
using?
The output of 'p4 -V' contains "Rev. P4/LINUX26X86/2012.1/459601
(2012/05/11)". That's probably the version of my command line client.
The output of "p4 info" contains "P4D/LINUX26X86_64/2011.1/428451
(2012/03/08)" --- that's probably the version of the server.
The version of git installation (by debian package) is 1:1.7.10-1 (as
reported by "dpkg -l git"). The package contains the file
"/usr/share/doc/git/contrib/fast-import/git-p4" which I copied to
$HOME/bin/git-p4 in order to have in $PATH and with executable bit.
Could it be, that I did something wrong here by making this manually?
> And which platform are you using?
Debian GNU/Linux.
I hope I provided all the needed information, of not please ask for more.
Cheers,
Ilya
From: Luke Diamand <hidden> Date: 2016-06-15 22:54:02
On 11/06/12 20:16, Ilya Dogolazky wrote:
Hi Luke!
06/11/2012 06:28 PM, ext Luke Diamand написал:
quoted
If you do something like "p4 describe 17473" what does that show?
First I see a line containing the change number, my colleague's name and
date, then the commit title (identical to one printed by "git log"),
then a list of files [every line begins with "... //xxx/yyy/"], then the
word "Differences" and then something looking very much like output of
'diff' command (the actual commit differences).
quoted
Are the files changed all contained with //kalma/xxx/yyy?
Yes, they are.
quoted
It could be that there's a p4 version problem going on - which version
of p4 are you
using?
The output of 'p4 -V' contains "Rev. P4/LINUX26X86/2012.1/459601
(2012/05/11)". That's probably the version of my command line client.
The output of "p4 info" contains "P4D/LINUX26X86_64/2011.1/428451
(2012/03/08)" --- that's probably the version of the server.
The version of git installation (by debian package) is 1:1.7.10-1 (as
reported by "dpkg -l git"). The package contains the file
"/usr/share/doc/git/contrib/fast-import/git-p4" which I copied to
$HOME/bin/git-p4 in order to have in $PATH and with executable bit.
Could it be, that I did something wrong here by making this manually?
That version of git-p4 seems different to the one in the repo. I think it's just a bit older.
> And which platform are you using?
Debian GNU/Linux.
I hope I provided all the needed information, of not please ask for more.
Can you try an experiment please. Try running the following commands. When I run them I get out a file that looks correct.
#!/bin/sh
export P4PORT=localhost:1234
mkdir db cli
(cd db && p4d &)
sleep 2
(cd cli && EDITOR=: p4 client && date >foo.c && p4 add foo.c && p4 submit -d 'x')
git-p4 clone //depot@all
I've been trying out Debian's 1.7.10.1 and it seems fine, other than having a slightly old version of git-p4 and it not being installed properly.
Hi Luke!
> #!/bin/sh
> export P4PORT=localhost:1234
> mkdir db cli
> ( cd db && p4d & )
> sleep 2
> ( cd cli && EDITOR=: p4 client && date >foo.c &&
> p4 add foo.c && p4 submit -d 'x' )
> git-p4 clone //depot@all
I installed p4d on my machine and executed the above script.
It works, the file foo.c is visible in the copy and one line patch is
visible by "git log -p". Everything is fine!
Then I realize, that the "git-p4" call in your script is communicating
with the p4 daemon directly, which is much more simple setup than I
tried to use before. Then I changed the clone command: instead of
$ git p4 clone //kalma/xxx/yyy@all
I now tried
$ git p4 clone //xxx/yyy@all
after setting P4PORT etc to point to the company's perforce server. And
it worked!
Then I even tried
$ git p4 clone //xxx@all
And it worked too (creating a huge git repository with the whole project).
Until today I tried to use the following setup: first clone the whole
perforce repository with p4 command line client to my machine ('kalma'
is its name) and then make a git repository by "git-p4 clone" from this
intermediate location (and it seems I did something wrong there: files
were visible in the intermediate location after the first step, but not
in the end location after git-p4). I read it somewhere in documentation
claiming that it's the only way to use git-p4. But now I see, that it
seems not to be necessary. Please clarify, is it okay to skip this
intermediate location and use git-p4 in the same way as your script does?
And another question, probably connected to above: Now I did this:
$ git p4 clone //xxx/yyy@all
$ cd yyy/zzz
$ edit readme.txt (which was already present there)
$ git commit readme.txt
$ git p4 rebase (Current branch master is up to date)
$ git p4 submit
That last step failed with following messages:
Submitting change 20073
... //xxx/yyy/zzz/readme.txt - warning: cannot submit from non-stream
client
No files to submit.
Submit failed -- fix problems above then use 'p4 submit -c 20073'.
Is it somehow related to my setup?
Cheers,
Ilya
From: Pete Wyckoff <hidden> Date: 2016-06-15 22:54:03
ilya.dogolazky@nokia.com wrote on Tue, 12 Jun 2012 12:37 +0300:
Hi Luke!
quoted
#!/bin/sh
export P4PORT=localhost:1234
mkdir db cli
( cd db && p4d & )
sleep 2
( cd cli && EDITOR=: p4 client && date >foo.c &&
p4 add foo.c && p4 submit -d 'x' )
git-p4 clone //depot@all
I installed p4d on my machine and executed the above script.
It works, the file foo.c is visible in the copy and one line patch
is visible by "git log -p". Everything is fine!
Then I realize, that the "git-p4" call in your script is
communicating with the p4 daemon directly, which is much more simple
setup than I tried to use before. Then I changed the clone command:
instead of
$ git p4 clone //kalma/xxx/yyy@all
I now tried
$ git p4 clone //xxx/yyy@all
after setting P4PORT etc to point to the company's perforce server.
And it worked!
Fascinating. So //kalma/xxx/yyy is a depot hosted in a p4d that runs
on your local box, but //xxx/yyy is the depot name hosted in
the company's p4d?
Then I even tried
$ git p4 clone //xxx@all
And it worked too (creating a huge git repository with the whole project).
Until today I tried to use the following setup: first clone the
whole perforce repository with p4 command line client to my machine
('kalma' is its name) and then make a git repository by "git-p4
clone" from this intermediate location (and it seems I did something
wrong there: files were visible in the intermediate location after
the first step, but not in the end location after git-p4). I read it
somewhere in documentation claiming that it's the only way to use
git-p4. But now I see, that it seems not to be necessary. Please
clarify, is it okay to skip this intermediate location and use
git-p4 in the same way as your script does?
I'm completely confused that //kalma/xxx/yyy even appeard to work
at all. Will be interested to see your P4PORT setting when using
that repo.
And another question, probably connected to above: Now I did this:
$ git p4 clone //xxx/yyy@all
$ cd yyy/zzz
$ edit readme.txt (which was already present there)
$ git commit readme.txt
$ git p4 rebase (Current branch master is up to date)
$ git p4 submit
That last step failed with following messages:
Submitting change 20073
... //xxx/yyy/zzz/readme.txt - warning: cannot submit from
non-stream client
No files to submit.
Submit failed -- fix problems above then use 'p4 submit -c 20073'.
Ooh. You're using the shiny new "streams" feature in p4,
I think. Can you play with "p4 stream" to see if one is
defined on //xxx or //xxx/yyy?.
Could be that the work-around is to use "p4 client" to
set the "Stream" field. This p4 forum post talks about
using "p4 client -s -S ...".
http://forums.perforce.com/index.php?/topic/1139-seeding-streams-from-existing-depots-failed/
which is explained at the bottom of this section:
http://www.perforce.com/perforce/doc.current/manuals/p4guide/06_codemgmt.html#1066766
If you can help us understand the problem a bit better,
a reasonable fix might be to detect this situation in
git-p4 and at least explain how to fix it. Since git-p4
does not create the client used for submit, we don't have
much control over its settings.
-- Pete
Hi Pete !
06/13/2012 01:24 AM, ext Pete Wyckoff написал:
Fascinating. So //kalma/xxx/yyy is a depot hosted in a p4d that runs
on your local box, but //xxx/yyy is the depot name hosted in
the company's p4d?
No. But now I think I understand, what I did wrong. There is no p4d
running on my own machine. "kalma" in this case is the name of the so
called "perforce client" I tried to use. And I think my error was to
express "please use perforce client 'kalma' to access depot '//xxx/yyy'"
by the string "//kalma/xxx/yyy", which is wrong. I'm pretty sure it was
not quite my own idea to do so, probably I misunderstood some piece of
documentation somewhere.
I'm completely confused that //kalma/xxx/yyy even appeard to work
at all. Will be interested to see your P4PORT setting when using
that repo.
And I think I understand now, why "//kalma/xxx/yyy" appeared to work: it
took all the commits, but as I wanted to have something beginning with
"kalma" I got no files, because everything begins with "xxx" (and couple
of other names, none of them is equal to 'kalma'). Does this explanation
seem reasonable?
Ooh. You're using the shiny new "streams" feature in p4,
I think. Can you play with "p4 stream" to see if one is
defined on //xxx or //xxx/yyy?.
Yes, alas I have to use it. Now I re-defined my "client" settings,
included the stream there and started from the beginning. Here is what I
did:
$ p4 client (and edit opened file .....)
Client xexe1 saved.
$ P4CLIENT=xexe1 p4 sync
//xxx/yyy/zzz/readme.txt#1 - added as /x/data/tmp/xexe/yyy/zzz/readme.txt
$ P4CLIENT=xexe1 git p4 clone //xxx/yyy@all ~/xexe1
Importing from //xxx/yyy into /home/ilya/xexe1
Initialized empty Git repository in /home/ilya/xexe1/.git/
Doing initial import of //xxx/yyy/ from revision #head into
refs/remotes/p4/master
$ cd ~/xexe1
$ vim zzz/readme.txt (and edit it)
$ git commit zzz/readme.txt
Until now everything worked fine, so now is time to submit the changes
on readme.txt file ("rebase" is not needed, as no changes happened yet
since I cloned).
$ P4CLIENT=xexe1 git p4 submit
Error: Cannot locate perforce checkout of //xxx/yyy/ in client view
This message comes from git-p4 script somewhere around line 1276 and I
don't understand its meaning.
Then I tried to set git-p4.useclientspec to "true" and I got the message:
$ P4CLIENT=xexe1 git p4 submit
Can't handle %n wildcards in view: //xxx/yyy/zzz/somefile%%1
This "%%1" is visible in client config (as opened in editor during
execution "P4CLIENT=xexe1 p4 client"), but I have not added it by
myself: this line [and many other similar lines in View: section] was
added after I set "Stream: //xxx/yyy" there. The beginning of View:
section looks like this now:
//xxx/yyy/zzz/... //xexe1/zzz/...
-//xxx/yyy/zzz/somefile%%1 //xexe1/zzz/somefile%%1
(yes, it begins with '-' and there are many other lines beginning with
'-', but this one is the only one containing '%%')
What do you think, is it now something wrong with git-p4 or is it again
something wrong in my setup?
Cheers,
Ilya
$ P4CLIENT=xexe1 git p4 submit
Error: Cannot locate perforce checkout of //xxx/yyy/ in client view
After some playing around with git-p4 script and adding debugging
printing I realized, that the solution is to do
$ P4CLIENT=xexe1 git p4 clone //xxx/yyy/zzz@all ~/xexe1
instead of just
$ P4CLIENT=xexe1 git p4 clone //xxx/yyy@all ~/xexe1
After that "git-p4 submit" started to work.
I still don't understand p4 enough in order to know why it's happening,
but now at least I can clone+change+rebase+submit files into the
perforce repository with git-p4, which is great.
Luke, Pete: thanks a lot for your help and patience!
Cheers,
Ilya
From: Luke Diamand <hidden> Date: 2016-06-15 22:54:03
On 13/06/12 13:56, Ilya Dogolazky wrote:
Hi !
06/13/2012 09:58 AM, Ilya Dogolazky написал:
quoted
$ P4CLIENT=xexe1 git p4 submit
Error: Cannot locate perforce checkout of //xxx/yyy/ in client view
After some playing around with git-p4 script and adding debugging
printing I realized, that the solution is to do
$ P4CLIENT=xexe1 git p4 clone //xxx/yyy/zzz@all ~/xexe1
instead of just
$ P4CLIENT=xexe1 git p4 clone //xxx/yyy@all ~/xexe1
After that "git-p4 submit" started to work.
I still don't understand p4 enough in order to know why it's happening,
but now at least I can clone+change+rebase+submit files into the
perforce repository with git-p4, which is great.
Luke, Pete: thanks a lot for your help and patience!
So - what is a p4 stream? I found some blurb on the Perforce website but
I was none the wiser after reading it.
Thanks!
Luke
So - what is a p4 stream? I found some blurb on the Perforce website but I
was none the wiser after reading it.
To be honest, I don't have any idea (and my whole p4 experience is
less than one week long). As our local p4 guru explained to me, a
"stream" is some kind of writeable area in depot and every "client"
can have 0 or 1 "streams". If a client has a stream, then it's called
"streamable" and one can submit changes to this particular area (which
means more or less directory) by using this particular client. I don't
know if this story is sane, but at least this explains my problems
while I tried to submit changes.
Cheers,
Ilya