From: Tor Arvid Lund <torarvid@gmail.com>
Date: Sun, 12 Sep 2010 19:54:07 GMT
Subject: Re: git-p4
Message-ID: <AANLkTi=NGsY3wDiTLwNLpw4TJMpiSY8A=az_=v2fYDLj@mail.gmail.com>
In-Reply-To: <4C8D14F9.90705@borg.org>

2010/9/12 Kent Borg <kentborg@borg.org>:
> Tor Arvid Lund wrote:
>> Ok, so if you call this on the cmd line, it should output sha1's on
>> all commits that will be submitted (in reverse order) to p4. If it
>> doesn't, this may well be a good place to dig for a solution.
>
> It does output the commits it wants to submit.  In my broken case far
> too many.
>
> I created a simple working case to see what working looks like, and the
> exact same command outputs just the one commit.  Looking more carefully
> at my gitg pictures in the good and bad cases, I realize that I in the
> broken case I probably don't have the graph I need.
>
>
> Good case:
>
>  (master)
>   |
>  (p4/HEAD)  (p4/master)
>   |
>  initial test import from existing depot
>
>
> Bad case:
>
>  (master)   trivial change I am trying to submit
>   |
>  (tmp)  commit with the "[git-p4: depot-paths = "//depot/[...blah
> blah...]": change  = 160991]" string at the end of the description
>   |
>  Merge remote branch 'p4/master'
>   | \
>   |  (p4/HEAD)  (p4/master)  a commit that is real work
<snip>

Hmm.. Let's define a "commit that contains that [git-p4:
depot-paths=...] stuff" as a git/perforce commit. Then I would say
that p4/master should always point to the most recent git/perforce
commit. In your "Bad case", it seems that it doesn't do that, because
the most recent git/perforce commit is (tmp).

When messing about with git-p4 I have sometimes messed up that
p4/master ref myself. I can normally fix it by setting it manually: In
git, all existing branches are simply files with a sha1 in them (or
symbolic refs that point to other refs, like "ref:
refs/heads/master"). You should thus be able to put the sha1 of your
(tmp) commit into refs/remotes/p4/master.

You could try that and see if git rev-list gives the expected result.

> I think my understanding of merges and rebases needs more depth...and I
> think I have mangled branches.
>
>
> I tried a checkout of master and a "git rebase remotes/p4/master" and
> that produced thousands of conflicts.  Was that due to my initial Linux
> sources put in on the Perforce side?

Well, when you do that, git will look back until it finds a common
ancestor commit of master and p4/master. I am guessing, that a common
ancestor for those branches does not exist in your case... If my guess
is correct, git will go back to the beginning of master (to linux
2.6.12-rc2) and try to apply each of those commits on top of
p4/master. Naturally, that will cause a world of pain and conflicts ;)

-Tor Arvid-