git-p4: commits are visible in history after 'git p4 clone', but not a single file present
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
Quoted 4 lines · Ilya Dogolazky
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!
Quoted 10 lines
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:
Quoted 8 lines
[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 написал:
Quoted 1 line
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 1 line
Are the files changed all contained with //kalma/xxx/yyy?
Yes, they are.
Quoted 3 lines
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?
Quoted 1 line
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
Quoted 19 lines · Ilya Dogolazky
Hi Luke!
06/11/2012 06:28 PM, ext Luke Diamand написал:
Quoted 1 line
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 1 line
Are the files changed all contained with //kalma/xxx/yyy?
Yes, they are.
Quoted 3 lines
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.
Quoted 8 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 4 lines
Cheers,
Ilya
Hi Luke!
Quoted 8 lines
#!/bin/sh
export P4PORT=localhost:1234
mkdir db cli
( cd db && p4d & )
sleep 2
( cd cli && EDITOR=: p4 client && date >foo.c &&
p4 addfoo.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
[email protected] wrote on Tue, 12 Jun 2012 12:37 +0300:
Quoted 19 lines
Hi Luke!
Quoted 8 lines
#!/bin/sh
export P4PORT=localhost:1234
mkdir db cli
( cd db && p4d & )
sleep 2
( cd cli && EDITOR=: p4 client && date >foo.c &&
p4 addfoo.c&& p4 submit -d 'x' )
git-p4 clone //depot@allI installed p4d on my machine and executed the above script. It works, the file
foo.cis 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
Quoted 5 lines
$ 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?
Quoted 4 lines
Then I even tried
$ git p4 clone //xxx@all And it worked too (creating a huge git repository with the whole project).
Quoted 10 lines
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.
Quoted 8 lines
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
Quoted 6 lines
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 написал:
Quoted 3 lines
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.
Quoted 3 lines
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?
Quoted 3 lines
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
Hi !
06/13/2012 09:58 AM, Ilya Dogolazky написал:
Quoted 2 lines
$ 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
Quoted 13 lines · Ilya Dogolazky
Hi !
06/13/2012 09:58 AM, Ilya Dogolazky написал:
Quoted 2 lines
$ P4CLIENT=xexe1 git p4 submit Error: Cannot locate perforce checkout of //xxx/yyy/ in client viewAfter 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
Quoted 7 lines
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
Hi !
2012/6/13 Luke Diamand <[email protected]>:
Quoted 2 lines
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