2010/9/12 Kent Borg <kentborg@xxxxxxxx>: > 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- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html