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

On Mon, Jun 11, 2012 at 11:03 AM, Ilya Dogolazky <ilya.dogolazky@nokia.com> wrote:

This is the right place!

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 написал:

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).

Yes, they are.

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

On 11/06/12 20:16, Ilya Dogolazky wrote:

That version of git-p4 seems different to the one in the repo. I think it's just a bit older.

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

ilya.dogolazky@nokia.com wrote on Tue, 12 Jun 2012 12:37 +0300:

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?

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.

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 написал:

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.

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?

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 написал:

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

On 13/06/12 13:56, Ilya Dogolazky wrote:

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 <luke@diamand.org>:

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