Re: git-p4: commits are visible in history after 'git p4 clone', but not a single file present

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