git-p4 Question

> Hopefully this is an appropriate place to ask questions about git-p4.
>
> I started at a company that wants to migrate from Perforce to Git. I'm
> new to Perforce and have been trying to learn just enough about it to
> get through this migration.

> On 04/20/2015 09:41 AM, FusionX86 wrote:
>>
>> Hopefully this is an appropriate place to ask questions about git-p4.
>>
>> I started at a company that wants to migrate from Perforce to Git. I'm
>> new to Perforce and have been trying to learn just enough about it to
>> get through this migration.
>
>
> You might also like to check out my git-p4raw project which imports directly
> from the raw repository files into a git repo using git fast-import
>
>     http://github.com/samv/git-p4raw
>
> Apparently it's my most popular github project :-).  YMMV.
>
> Sam.

> Hello,
>
> Hopefully this is an appropriate place to ask questions about git-p4.
>
> I started at a company that wants to migrate from Perforce to Git. I'm
> new to Perforce and have been trying to learn just enough about it to
> get through this migration. Anyway, I've been playing with git-p4 and
> have one question/problem to discuss.
>
> After setting up the p4 cli client I can 'p4 sync' some
> //depot/main/app1 which pulls down the files I would expect from the
> Perforce server. If I use 'git p4 clone //depot/main/app1', I get:
>
> "Doing initial import of //depot/main/app1/ from revision #head into
> refs/remotes/p4/master"
>
> But I don't get any files from that depot/folder pulled down. I can
> git p4 clone other depot/folders though and get some files. I suspect
> that I'm just not understanding how the git-p4 module works.

>
> Basically, I'm hoping to setup a live sync of Perforce to Git of
> certain depots in preparation for the migration. Also, if anyone has
> pointers or guides for this type of migration, any help is
> appreciated.

> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

> On 20/04/15 17:41, FusionX86 wrote:
>>
>> Hello,
>>
>> Hopefully this is an appropriate place to ask questions about git-p4.
>>
>> I started at a company that wants to migrate from Perforce to Git. I'm
>> new to Perforce and have been trying to learn just enough about it to
>> get through this migration. Anyway, I've been playing with git-p4 and
>> have one question/problem to discuss.
>>
>> After setting up the p4 cli client I can 'p4 sync' some
>> //depot/main/app1 which pulls down the files I would expect from the
>> Perforce server. If I use 'git p4 clone //depot/main/app1', I get:
>>
>> "Doing initial import of //depot/main/app1/ from revision #head into
>> refs/remotes/p4/master"
>>
>> But I don't get any files from that depot/folder pulled down. I can
>> git p4 clone other depot/folders though and get some files. I suspect
>> that I'm just not understanding how the git-p4 module works.
>
>
> You could try doing the clone with '-v' to get a bit more information.
>
>>
>> Basically, I'm hoping to setup a live sync of Perforce to Git of
>> certain depots in preparation for the migration. Also, if anyone has
>> pointers or guides for this type of migration, any help is
>> appreciated.
>
>
> I've done something similar in the past. You'll want to enable the
> --preserve-user option, for which you will need admin rights.
>
> If it's a one-way mirror (p4-to-git) then just run git-p4 periodically (if
> you use cron, then try to avoid having two or more instances running at the
> same time).
>
> If you want it to be two-way then it gets a bit more complicated.
>
> You might also want to consider using git fusion, which is Perforce's take
> on this problem. I've not used it myself.
>
> From past experience though I would say the biggest problem is getting
> developers to switch from the P4 mindset (centralized; code review hard to
> do or ignored) to the git mindset (decentralized; code review actively
> supported by the version control system).
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

> Hi Luke,
>
> Using -v was a good suggestion. Unfortunately I still don't see what
> the problem is. I'm starting to think that maybe I should just create
> the client views I need and setup a cron job that p4 syncs and then
> git commits/pushes.
>
> The --preserve-user option is for submitting back to Perforce correct?
> I'm hoping to get away with a one-way sync from Perforce to Git...and
> then eventually just cut over to Git.
>
> I also looked at git fusion, but unfortunately the version of Perforce
> we're running (2012.1) doesn't meet the requirements for fusion. I
> wish it did.
>
> Good point on developer mindset. I think we definitely have some
> training and habit changing in the future.
>
> Thanks for the suggestions and pointers, it's much appreciated.
>
> On Mon, Apr 20, 2015 at 1:26 PM, Luke Diamand <luke@diamand.org> wrote:
>> On 20/04/15 17:41, FusionX86 wrote:
>>>
>>> Hello,
>>>
>>> Hopefully this is an appropriate place to ask questions about git-p4.
>>>
>>> I started at a company that wants to migrate from Perforce to Git. I'm
>>> new to Perforce and have been trying to learn just enough about it to
>>> get through this migration. Anyway, I've been playing with git-p4 and
>>> have one question/problem to discuss.
>>>
>>> After setting up the p4 cli client I can 'p4 sync' some
>>> //depot/main/app1 which pulls down the files I would expect from the
>>> Perforce server. If I use 'git p4 clone //depot/main/app1', I get:
>>>
>>> "Doing initial import of //depot/main/app1/ from revision #head into
>>> refs/remotes/p4/master"
>>>
>>> But I don't get any files from that depot/folder pulled down. I can
>>> git p4 clone other depot/folders though and get some files. I suspect
>>> that I'm just not understanding how the git-p4 module works.
>>
>>
>> You could try doing the clone with '-v' to get a bit more information.
>>
>>>
>>> Basically, I'm hoping to setup a live sync of Perforce to Git of
>>> certain depots in preparation for the migration. Also, if anyone has
>>> pointers or guides for this type of migration, any help is
>>> appreciated.
>>
>>
>> I've done something similar in the past. You'll want to enable the
>> --preserve-user option, for which you will need admin rights.
>>
>> If it's a one-way mirror (p4-to-git) then just run git-p4 periodically (if
>> you use cron, then try to avoid having two or more instances running at the
>> same time).
>>
>> If you want it to be two-way then it gets a bit more complicated.
>>
>> You might also want to consider using git fusion, which is Perforce's take
>> on this problem. I've not used it myself.
>>
>> From past experience though I would say the biggest problem is getting
>> developers to switch from the P4 mindset (centralized; code review hard to
>> do or ignored) to the git mindset (decentralized; code review actively
>> supported by the version control system).
>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe git" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>

> Can you post up the output from 'git p4 clone', and also see what the
> output from doing this is:
>
> $ p4 print //depot/some/branch/missingfile.c
>
>
>
> On 21 April 2015 at 14:33, FusionX86 <fusionx86@gmail.com> wrote:
>> Hi Luke,
>>
>> Using -v was a good suggestion. Unfortunately I still don't see what
>> the problem is. I'm starting to think that maybe I should just create
>> the client views I need and setup a cron job that p4 syncs and then
>> git commits/pushes.
>>
>> The --preserve-user option is for submitting back to Perforce correct?
>> I'm hoping to get away with a one-way sync from Perforce to Git...and
>> then eventually just cut over to Git.
>>
>> I also looked at git fusion, but unfortunately the version of Perforce
>> we're running (2012.1) doesn't meet the requirements for fusion. I
>> wish it did.
>>
>> Good point on developer mindset. I think we definitely have some
>> training and habit changing in the future.
>>
>> Thanks for the suggestions and pointers, it's much appreciated.
>>
>> On Mon, Apr 20, 2015 at 1:26 PM, Luke Diamand <luke@diamand.org> wrote:
>>> On 20/04/15 17:41, FusionX86 wrote:
>>>>
>>>> Hello,
>>>>
>>>> Hopefully this is an appropriate place to ask questions about git-p4.
>>>>
>>>> I started at a company that wants to migrate from Perforce to Git. I'm
>>>> new to Perforce and have been trying to learn just enough about it to
>>>> get through this migration. Anyway, I've been playing with git-p4 and
>>>> have one question/problem to discuss.
>>>>
>>>> After setting up the p4 cli client I can 'p4 sync' some
>>>> //depot/main/app1 which pulls down the files I would expect from the
>>>> Perforce server. If I use 'git p4 clone //depot/main/app1', I get:
>>>>
>>>> "Doing initial import of //depot/main/app1/ from revision #head into
>>>> refs/remotes/p4/master"
>>>>
>>>> But I don't get any files from that depot/folder pulled down. I can
>>>> git p4 clone other depot/folders though and get some files. I suspect
>>>> that I'm just not understanding how the git-p4 module works.
>>>
>>>
>>> You could try doing the clone with '-v' to get a bit more information.
>>>
>>>>
>>>> Basically, I'm hoping to setup a live sync of Perforce to Git of
>>>> certain depots in preparation for the migration. Also, if anyone has
>>>> pointers or guides for this type of migration, any help is
>>>> appreciated.
>>>
>>>
>>> I've done something similar in the past. You'll want to enable the
>>> --preserve-user option, for which you will need admin rights.
>>>
>>> If it's a one-way mirror (p4-to-git) then just run git-p4 periodically (if
>>> you use cron, then try to avoid having two or more instances running at the
>>> same time).
>>>
>>> If you want it to be two-way then it gets a bit more complicated.
>>>
>>> You might also want to consider using git fusion, which is Perforce's take
>>> on this problem. I've not used it myself.
>>>
>>> From past experience though I would say the biggest problem is getting
>>> developers to switch from the P4 mindset (centralized; code review hard to
>>> do or ignored) to the git mindset (decentralized; code review actively
>>> supported by the version control system).
>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe git" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>

> Hi Luke,
>
> I found a silly mistake I was making in the command I've been using.
> The folder under the depot should have been capitalized, but it
> wasn't. Also, I expected that if there was a problem with the command,
> it would fail with some message instead of creating an empty local git
> repo.

> On 23/04/15 14:42, FusionX86 wrote:
>>
>> Hi Luke,
>>
>> I found a silly mistake I was making in the command I've been using.
>> The folder under the depot should have been capitalized, but it
>> wasn't. Also, I expected that if there was a problem with the command,
>> it would fail with some message instead of creating an empty local git
>> repo.
>
>
> I would expect that as well - it will usually create the empty git repo, but
> it should then fail with an error message, like this:
>
> $ git p4 clone //depot/main/nosuchpath
> Importing from //depot/main/nosuchpath into nosuchpath
> Initialized empty Git repository in
> /home/lgd/p4-hacking/git/nosuchpath/.git/
> Doing initial import of //depot/main/nosuchpath/ from revision #head into
> refs/remotes/p4/master
> p4 returned an error: //depot/main/nosuchpath/...#head - no such file(s).
>
> $ echo $?
> 1
>
> If you get a moment can you send your command output; if it's not doing
> something like the above, then it's a bug.
>
> Thanks!
>
> Luke
>

> I get an error if I misspell part of the path. For example, if I type
> //depot/maain instead of //depot/main I will get the "no such files"
> message you indicated. BUT using incorrect case like //depot/main
> instead of //depot/Main doesn't return any error, but still completes
> and creates an empty repo. If it does require correct case, then it
> should throw an error for //depot/main as well.