git-p4

git-p4

[Kent Borg]

I have a git-p4 question: I work in a Perforce shop and am doing Linux
kernel work, I need to share that work with colleagues who see the world
as a Perforce place.  The kernel I have came from Linus' tree and has a
lot of history.  When I try to do my first a "git p4 submit" it chokes
as it looks back in the entire git history until it fails looking for
the ancestor of the first commit (linux-2.6.12-rc2!), I think it is
looking for the last time it did a git-p4 submit so it knows how far
back to go--but it has never done a submit in this new relationship
between p4 and git.  There is plenty of git history that is not
reflected in p4, and I don't want it in p4, I just want new work in p4.

I fear that git-p4 is for git people to contribute to bits natively
p4-homed code, not this case where the code is natively git-homed code
and it is the p4 people who will be contributing bits. 

My attempt at a work around was this:

 - create a director on the p4 side, and from the p4 side submit the
files that match my latest git submit.

 - sync with git-p4

 - try to submit a file with git-p4...and that fails as it runs all the
way back through the history.  (Thank goodness it didn't succeed in
submitting kernel activity since 2005!)


I was hoping I could merge the p4/master with master to force a stopping
point in the git-p4 submit, but that doesn't work, it is searching
through git history to find the stopping point.  What might I put in the
git history to force the stop (or maybe make a change to git-p4 to help
my plight along)?


Thanks,

-kb, the Kent who has always hated Perforce, alas.

Re: git-p4

[Alejandro Riveira Fernández]

El Fri, 10 Sep 2010 15:54:16 -0400
Kent Borg <kentborg@borg.org> escribió:

 [ CCing git mailing list. Looks like a better place to ask this question]

> I have a git-p4 question: I work in a Perforce shop and am doing Linux
> kernel work, I need to share that work with colleagues who see the world
> as a Perforce place.  The kernel I have came from Linus' tree and has a
> lot of history.  When I try to do my first a "git p4 submit" it chokes
> as it looks back in the entire git history until it fails looking for
> the ancestor of the first commit (linux-2.6.12-rc2!), I think it is
> looking for the last time it did a git-p4 submit so it knows how far
> back to go--but it has never done a submit in this new relationship
> between p4 and git.  There is plenty of git history that is not
> reflected in p4, and I don't want it in p4, I just want new work in p4.
> 
> I fear that git-p4 is for git people to contribute to bits natively
> p4-homed code, not this case where the code is natively git-homed code
> and it is the p4 people who will be contributing bits. 
> 
> My attempt at a work around was this:
> 
>  - create a director on the p4 side, and from the p4 side submit the
> files that match my latest git submit.
> 
>  - sync with git-p4
> 
>  - try to submit a file with git-p4...and that fails as it runs all the
> way back through the history.  (Thank goodness it didn't succeed in
> submitting kernel activity since 2005!)
> 
> 
> I was hoping I could merge the p4/master with master to force a stopping
> point in the git-p4 submit, but that doesn't work, it is searching
> through git history to find the stopping point.  What might I put in the
> git history to force the stop (or maybe make a change to git-p4 to help
> my plight along)?
> 
> 
> Thanks,
> 
> -kb, the Kent who has always hated Perforce, alas.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: git-p4

[Tor Arvid Lund]

2010/9/10 Alejandro Riveira Fernández <ariveira@gmail.com>:
> El Fri, 10 Sep 2010 15:54:16 -0400
> Kent Borg <kentborg@borg.org> escribió:
>
>  [ CCing git mailing list. Looks like a better place to ask this question]
>
>> I have a git-p4 question: I work in a Perforce shop and am doing Linux
>> kernel work, I need to share that work with colleagues who see the world
>> as a Perforce place.  The kernel I have came from Linus' tree and has a
>> lot of history.  When I try to do my first a "git p4 submit" it chokes
>> as it looks back in the entire git history until it fails looking for
>> the ancestor of the first commit (linux-2.6.12-rc2!), I think it is
>> looking for the last time it did a git-p4 submit so it knows how far
>> back to go--but it has never done a submit in this new relationship
>> between p4 and git.  There is plenty of git history that is not
>> reflected in p4, and I don't want it in p4, I just want new work in p4.

Yes, you are right in that git-p4 looks for the last point in history
where p4 and git were "in sync".

>> I fear that git-p4 is for git people to contribute to bits natively
>> p4-homed code, not this case where the code is natively git-homed code
>> and it is the p4 people who will be contributing bits.

This is also correct, I'd say.

>> My attempt at a work around was this:
>>
>>  - create a director on the p4 side, and from the p4 side submit the
>> files that match my latest git submit.
>>
>>  - sync with git-p4

This is how I would do it too...

>>  - try to submit a file with git-p4...and that fails as it runs all the
>> way back through the history.  (Thank goodness it didn't succeed in
>> submitting kernel activity since 2005!)

Well, when you did the "sync with git-p4", did it create a branch in
refs/remotes/p4/master or something like that? I think that's
generally how it solves the issue of knowing what to submit to p4; On
the git side you have a number of commits that you _don't_ want to
submit, and the most recent of these commits should have a log message
that ends with:

[git-p4: depot-paths = "//Path/To/Your/Project/": change = 30049]

.. where the 'change' number is the number of the perforce changelist
you synced using git-p4.

So - work that you want to submit to p4 should be rebased on top of
such a commit. Then it should work to do git-p4 submit.

-Tor Arvid-