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 | | | more real work | | | more real work | | Merge remote branch 'p4/master' | \| some commit in my thrashing about | | | more real work | | . . . . . . | | | initial import of no-history linux sources that I put in manually via Perforce | . . . | Linux-2.6.12-rc2 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? How do I untangle myself here? I think I am about to be saved, thanks so much in advance for that! -kb -- 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