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

[Pete Wyckoff <pw@padd.com>]

ilya.dogolazky@nokia.com wrote on Tue, 12 Jun 2012 12:37 +0300:
> 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!

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