4 replies to this topic

[P4rdefauw]

There was a good question on StackOverflow about using multiple branches with git-p4.  (If you haven't heard of it, git-p4 is part of the git project, and provides a way to sync data between a local git repository and a Perforce server.)

I did get multiple branches syncing using git-p4 once, using the --detect-branches option.  However I don't use it much and I didn't take great notes when I was doing the configuration.

Here's what I do recall.  If anyone can flesh out these steps, that would be very helpful.

Perforce branch structure

I experimented with a simple branch structure from the Perforce sample depot, with a main branch and two release branches.

 
//depot/Jam/MAIN
//depot/Jam/REL2.1
//depot/Jam/REL2.2

Perforce branch specs

I then created a branch spec for each release branch, using the same name as the branch folder.  (I don't think that's strictly necessary.)

 
p4 branch REL2.1 -> View: //depot/Jam/MAIN/... //depot/Jam/REL2.1/...
p4 branch REL2.2 -> View: //depot/Jam/MAIN/... //depot/Jam/REL2.2/...

Perforce workspace

I made a workspace that maps in all of my Jam branches.

 
p4 client bruno_ws_jam -> View: //depot/Jam/... //bruno_ws_jam/depot/Jam/...

git-p4 setup

I made a new directory for git-p4 to use, and copied in the p4config file from my Perforce workspace to provide the right Perforce connection settings.  Then I set up a git repo and initialized git-p4.

 
>  git init .
>  git p4 sync //depot/Jam@all --detect-branches

git-p4 usage

Now I can see the three Jam branches in git:

 
> git branch -r
  p4/Jam/MAIN
  p4/Jam/REL2.1
  p4/Jam/REL2.2

Now I want to map git branches to these Jam branches:

 
> git checkout -b master p4/Jam/MAIN
> git checkout -b REL2.1 p4/Jam/REL2.1
> git checkout -b REL2.2 p4/Jam/REL2.2

> git branch
  REL2.1
* REL2.2
  master

Now let's make an edit on two branches.

 
>  git checkout master
>  vim .\src\glob.c
>  git commit -am "main"
>  git checkout REL2.1
>  vim .\src\glob.c
>  git commit -am "rel2.1"

Now I can push these changes upstream.  I just need to run the sequence of commands on each git branch, and the changes will go the appropriate upstream Perforce branch.

 
>  git checkout REL2.1
>  git p4 rebase
>  git p4 submit
>  git checkout master
>  git p4 rebase
>  git p4 submit

I now see those two changes replayed into the appropriate branches in Perforce.

> p4 changes -m2 //depot/Jam/...
Change 12154 on 2012/02/06 by bruno@bruno_ws_jam 'main '
Change 12153 on 2012/02/06 by bruno@bruno_ws_jam 'rel2.1 '
> p4 describe -s 12154
Change 12154 by bruno@bruno_ws_jam on 2012/02/06 09:47:17

		main

Affected files ...

... //depot/Jam/MAIN/src/glob.c#6 edit

> p4 describe -s 12153
Change 12153 by bruno@bruno_ws_jam on 2012/02/06 09:47:02

		rel2.1

Affected files ...

... //depot/Jam/REL2.1/src/glob.c#2 edit

[Jeff Bowles]

P4rdefauw, on 06 February 2012 - 04:42 PM, said:

There was a good question on StackOverflow about using multiple branches with git-p4.

I agree that git-p4 has a lot of merit, is a significant project, etc.

The issue I see with "multiple branches" in git vs. Perforce is that it enforces an assumption that isn't valid:

• [invalid assumption] you can do the merges between branches in 'git' or in 'perforce', your choice, and the work can appear in the other SCM system.

The assumption is invalid because it is incomplete: the metadata on the target system does not necessarily track the merge choices/metadata in the system that did the merge.

It is an almost-but-not-quite scenario, because the metadata that reflects the merge isn't carried along and so the work looks like separate edits/etc when pushed back to Perforce.  The implied triangulation does not work.

You can architecture workflows and branch topology to make this a non-issue, by procedurally walking around the scenario. ("Always do branches in _____ and the other is just for dev-work," is one brute-force policy to do that.)

===

For me, "git" is very good - but branch operations in "git" do not exist in an beginner or intermediate scenario. If you're using 'git' and doing branching, the tool assumes you're a power-user.  That doesn't always match the real-world engineers using it, who are the developers in your company who don't have the time (or interest) in trolling such forums as this one.  (Those are the "just tell me where to do the checkin, I do not care to know more, and can someone else do the merges and testing for me?" sort of developers.)

[P4rdefauw]

I think the general idea is that you maintain your 'master' branches in Perforce and create remote tracking branches in git.  You can't push up merge history from git to Perforce (yet).  So it's really just a more convenient way to maintain git-p4 connections to several Perforce branches.

On the learning curve front... I'm sensing a real difference of opinion in the community here.  Some folks seem to take to git very naturally, while others find it a bit esoteric.  I wonder if there is a gap between those who really enjoy playing with new tools and technologies versus those who just, as you say, want to check in and forget about it?

[Raffi Khatchadourian]

P4rdefauw, on 06 February 2012 - 04:42 PM, said:

There was a good question on StackOverflow about using multiple branches with git-p4.

I followed the above steps but I am receiving the following error message from git-p4:

Quote

Could not detect main branch. No checkout/master branch created.

Is it due to the way my branches are configured?

[P4rdefauw]

Raffi Khatchadourian, on 16 April 2012 - 02:53 PM, said:

I followed the above steps but I am receiving the following error message from git-p4:



Is it due to the way my branches are configured?

Could be - can you send me more information about your branch configuration in a private message?