{"thread":{"id":"25070","subject":"Re: git-p4","startedAt":"2010-09-10T21:53:23Z","lastAt":"2010-09-16T13:54:03Z","messageCount":14,"participants":["Alejandro Riveira Fernández","Tor Arvid Lund","Kent Borg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"150479","messageId":"20100910235323.773d2c5b@varda","threadId":"25070","inReplyTo":"4C8A8CE8.90600@borg.org","subject":"Re: git-p4","fromName":"Alejandro Riveira Fernández","fromEmail":"ariveira@gmail.com","sentAt":"2010-09-10T21:53:23Z","receivedAt":"2010-09-10T21:53:23Z","isPatch":false,"sender":{"key":"ariveira@gmail.com","avatar":null},"body":"El Fri, 10 Sep 2010 15:54:16 -0400\nKent Borg escribió:\n\n [ CCing git mailing list. Looks like a better place to ask this question]\n\n> I have a git-p4 question: I work in a Perforce shop and am doing Linux\n> kernel work, I need to share that work with colleagues who see the world\n> as a Perforce place. The kernel I have came from Linus' tree and has a\n> lot of history. When I try to do my first a \"git p4 submit\" it chokes\n> as it looks back in the entire git history until it fails looking for\n> the ancestor of the first commit (linux-2.6.12-rc2!), I think it is\n> looking for the last time it did a git-p4 submit so it knows how far\n> back to go--but it has never done a submit in this new relationship\n> between p4 and git. There is plenty of git history that is not\n> reflected in p4, and I don't want it in p4, I just want new work in p4.\n> \n> I fear that git-p4 is for git people to contribute to bits natively\n> p4-homed code, not this case where the code is natively git-homed code\n> and it is the p4 people who will be contributing bits. \n> \n> My attempt at a work around was this:\n> \n> - create a director on the p4 side, and from the p4 side submit the\n> files that match my latest git submit.\n> \n> - sync with git-p4\n> \n> - try to submit a file with git-p4...and that fails as it runs all the\n> way back through the history. (Thank goodness it didn't succeed in\n> submitting kernel activity since 2005!)\n> \n> \n> I was hoping I could merge the p4/master with master to force a stopping\n> point in the git-p4 submit, but that doesn't work, it is searching\n> through git history to find the stopping point. What might I put in the\n> git history to force the stop (or maybe make a change to git-p4 to help\n> my plight along)?\n> \n> \n> Thanks,\n> \n> -kb, the Kent who has always hated Perforce, alas.\n> \n> --\n> To unsubscribe from this list: send the line \"unsubscribe linux-kernel\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> Please read the FAQ at http://www.tux.org/lkml/\n"},{"id":"150511","messageId":"AANLkTinmG5BU+yswWQ8=cRKT5WL_h8vWuUCu2PjZYb87@mail.gmail.com","threadId":"25070","inReplyTo":"20100910235323.773d2c5b@varda","subject":"Re: git-p4","fromName":"Tor Arvid Lund","fromEmail":"torarvid@gmail.com","sentAt":"2010-09-11T18:42:41Z","receivedAt":"2010-09-11T18:42:41Z","isPatch":false,"sender":{"key":"torarvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/439758?v=4"},"body":"2010/9/10 Alejandro Riveira Fernández :\n> El Fri, 10 Sep 2010 15:54:16 -0400\n> Kent Borg escribió:\n>\n>  [ CCing git mailing list. Looks like a better place to ask this question]\n>\n>> I have a git-p4 question: I work in a Perforce shop and am doing Linux\n>> kernel work, I need to share that work with colleagues who see the world\n>> as a Perforce place.  The kernel I have came from Linus' tree and has a\n>> lot of history.  When I try to do my first a \"git p4 submit\" it chokes\n>> as it looks back in the entire git history until it fails looking for\n>> the ancestor of the first commit (linux-2.6.12-rc2!), I think it is\n>> looking for the last time it did a git-p4 submit so it knows how far\n>> back to go--but it has never done a submit in this new relationship\n>> between p4 and git.  There is plenty of git history that is not\n>> reflected in p4, and I don't want it in p4, I just want new work in p4.\n\nYes, you are right in that git-p4 looks for the last point in history\nwhere p4 and git were \"in sync\".\n\n>> I fear that git-p4 is for git people to contribute to bits natively\n>> p4-homed code, not this case where the code is natively git-homed code\n>> and it is the p4 people who will be contributing bits.\n\nThis is also correct, I'd say.\n\n>> My attempt at a work around was this:\n>>\n>>  - create a director on the p4 side, and from the p4 side submit the\n>> files that match my latest git submit.\n>>\n>>  - sync with git-p4\n\nThis is how I would do it too...\n\n>>  - try to submit a file with git-p4...and that fails as it runs all the\n>> way back through the history.  (Thank goodness it didn't succeed in\n>> submitting kernel activity since 2005!)\n\nWell, when you did the \"sync with git-p4\", did it create a branch in\nrefs/remotes/p4/master or something like that? I think that's\ngenerally how it solves the issue of knowing what to submit to p4; On\nthe git side you have a number of commits that you _don't_ want to\nsubmit, and the most recent of these commits should have a log message\nthat ends with:\n\n[git-p4: depot-paths = \"//Path/To/Your/Project/\": change = 30049]\n\n.. where the 'change' number is the number of the perforce changelist\nyou synced using git-p4.\n\nSo - work that you want to submit to p4 should be rebased on top of\nsuch a commit. Then it should work to do git-p4 submit.\n\n-Tor Arvid-\n"},{"id":"150538","messageId":"4C8CF231.6090403@borg.org","threadId":"25070","inReplyTo":"AANLkTinmG5BU+yswWQ8=cRKT5WL_h8vWuUCu2PjZYb87@mail.gmail.com","subject":"Re: git-p4","fromName":"Kent Borg","fromEmail":"kentborg@borg.org","sentAt":"2010-09-12T15:30:57Z","receivedAt":"2010-09-12T15:30:57Z","isPatch":false,"sender":{"key":"kentborg@borg.org","avatar":null},"body":"Tor Arvid Lund wrote:\n> [git-p4: depot-paths = \"//Path/To/Your/Project/\": change = 30049]\n> .. where the 'change' number is the number of the perforce changelist\n> you synced using git-p4.\n>\n> So - work that you want to submit to p4 should be rebased on top of\n> such a commit. Then it should work to do git-p4 submit.\n> \n\nThat doesn't work. I am suspecting there is a tangle in my branches.\n\nFiring up a Python session and manually running the git-p4\nfindUpstreamBranchPoint() I get back something reminiscent of the commit\nI made at your suggestion:\n\n ['remotes/p4/master', {'change': '160991', 'depot-paths':\n['//depot/imgeng/sw/inferno/kernel/linux-2.6.33-quatro']}]\n\nI thought it looked reasonable, but when I try to run the git p4 summit,\nat line 811 in git-p4 it is doing:\n\n git rev-list --no-merges remotes/p4/master..master\n\nAnd then reversing the results and trying to apply them all, starting\nwith 1da177e (which is Linux-2.16.12-rc), and again it fails. (Again,\nthank goodness it failed at that.) How is git rev-list supposed to get\na limited list back?\n\nAnyone spot my silliness? Next I'm going to see if I can create a\nnormal (and working) case for comparison. (As a newbie git is one\nthing, trying to understand git-p4 at the same time makes it that much\nharder.)\n\n\nThanks a bunch,\n\n-kb, the Kent who Monday morning (UTC-0400) would love to casually say\n\"Oh, yes, git-p4 is working great, both directions, no problem.\".\n"},{"id":"150540","messageId":"AANLkTi=yJ5kVA17+40xc6NpEczFjgmYh7=w5k=GL_U9w@mail.gmail.com","threadId":"25070","inReplyTo":"4C8CF231.6090403@borg.org","subject":"Re: git-p4","fromName":"Tor Arvid Lund","fromEmail":"torarvid@gmail.com","sentAt":"2010-09-12T17:22:27Z","receivedAt":"2010-09-12T17:22:27Z","isPatch":false,"sender":{"key":"torarvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/439758?v=4"},"body":"2010/9/12 Kent Borg :\n> Firing up a Python session and manually running the git-p4\n> findUpstreamBranchPoint() I get back something reminiscent of the commit\n> I made at your suggestion:\n>\n>  ['remotes/p4/master', {'change': '160991', 'depot-paths':\n> ['//depot/imgeng/sw/inferno/kernel/linux-2.6.33-quatro']}]\n>\n> I thought it looked reasonable, but when I try to run the git p4 summit,\n> at line 811 in git-p4 it is doing:\n>\n>  git rev-list --no-merges remotes/p4/master..master\n\nOk, so if you call this on the cmd line, it should output sha1's on\nall commits that will be submitted (in reverse order) to p4. If it\ndoesn't, this may well be a good place to dig for a solution.\n\nSay that you have only one commit to submit to p4. We'll call it X.\n\nThe parent of X should then be the commit that remotes/p4/master is\npointing to. If it isn't, you can try to:\n\n1) git checkout -b my_p4_branch p4/master\n2) git cherry-pick X # we'll call this cherry-picked commit Y\n3) git rev-list --no-merges remotes/p4/master..my_p4_branch\n * if it lists Y and only Y, try\n4) git p4 submit\n\n-Tor Arvid-\n"},{"id":"150543","messageId":"4C8D14F9.90705@borg.org","threadId":"25070","inReplyTo":"AANLkTi=yJ5kVA17+40xc6NpEczFjgmYh7=w5k=GL_U9w@mail.gmail.com","subject":"Re: git-p4","fromName":"Kent Borg","fromEmail":"kentborg@borg.org","sentAt":"2010-09-12T17:59:21Z","receivedAt":"2010-09-12T17:59:21Z","isPatch":false,"sender":{"key":"kentborg@borg.org","avatar":null},"body":"Tor Arvid Lund wrote:\n> Ok, so if you call this on the cmd line, it should output sha1's on\n> all commits that will be submitted (in reverse order) to p4. If it\n> doesn't, this may well be a good place to dig for a solution.\n\nIt does output the commits it wants to submit. In my broken case far\ntoo many.\n\nI created a simple working case to see what working looks like, and the\nexact same command outputs just the one commit. Looking more carefully\nat my gitg pictures in the good and bad cases, I realize that I in the\nbroken case I probably don't have the graph I need.\n\n\nGood case:\n\n (master)\n |\n (p4/HEAD) (p4/master)\n |\n initial test import from existing depot\n\n\nBad case:\n\n (master) trivial change I am trying to submit\n |\n (tmp) commit with the \"[git-p4: depot-paths = \"//depot/[...blah\nblah...]\": change = 160991]\" string at the end of the description\n |\n Merge remote branch 'p4/master'\n | \\\n | (p4/HEAD) (p4/master) a commit that is real work\n | |\n | more real work\n | |\n | more real work\n | |\n Merge remote branch 'p4/master'\n | \\|\n some commit in my thrashing about\n | |\n | more real work\n | |\n . .\n . .\n . .\n | |\n | initial import of no-history linux sources that I put in manually\nvia Perforce\n |\n .\n .\n .\n |\n Linux-2.6.12-rc2\n \n\nI think my understanding of merges and rebases needs more depth...and I\nthink I have mangled branches.\n\n\nI tried a checkout of master and a \"git rebase remotes/p4/master\" and\nthat produced thousands of conflicts. Was that due to my initial Linux\nsources put in on the Perforce side?\n\n\nHow do I untangle myself here?\n\n\nI think I am about to be saved, thanks so much in advance for that!\n\n\n-kb\n"},{"id":"150548","messageId":"AANLkTi=NGsY3wDiTLwNLpw4TJMpiSY8A=az_=v2fYDLj@mail.gmail.com","threadId":"25070","inReplyTo":"4C8D14F9.90705@borg.org","subject":"Re: git-p4","fromName":"Tor Arvid Lund","fromEmail":"torarvid@gmail.com","sentAt":"2010-09-12T19:54:07Z","receivedAt":"2010-09-12T19:54:07Z","isPatch":false,"sender":{"key":"torarvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/439758?v=4"},"body":"2010/9/12 Kent Borg :\n> Tor Arvid Lund wrote:\n>> Ok, so if you call this on the cmd line, it should output sha1's on\n>> all commits that will be submitted (in reverse order) to p4. If it\n>> doesn't, this may well be a good place to dig for a solution.\n>\n> It does output the commits it wants to submit.  In my broken case far\n> too many.\n>\n> I created a simple working case to see what working looks like, and the\n> exact same command outputs just the one commit.  Looking more carefully\n> at my gitg pictures in the good and bad cases, I realize that I in the\n> broken case I probably don't have the graph I need.\n>\n>\n> Good case:\n>\n>  (master)\n>   |\n>  (p4/HEAD)  (p4/master)\n>   |\n>  initial test import from existing depot\n>\n>\n> Bad case:\n>\n>  (master)   trivial change I am trying to submit\n>   |\n>  (tmp)  commit with the \"[git-p4: depot-paths = \"//depot/[...blah\n> blah...]\": change  = 160991]\" string at the end of the description\n>   |\n>  Merge remote branch 'p4/master'\n>   | \\\n>   |  (p4/HEAD)  (p4/master)  a commit that is real work\n\n\nHmm.. Let's define a \"commit that contains that [git-p4:\ndepot-paths=...] stuff\" as a git/perforce commit. Then I would say\nthat p4/master should always point to the most recent git/perforce\ncommit. In your \"Bad case\", it seems that it doesn't do that, because\nthe most recent git/perforce commit is (tmp).\n\nWhen messing about with git-p4 I have sometimes messed up that\np4/master ref myself. I can normally fix it by setting it manually: In\ngit, all existing branches are simply files with a sha1 in them (or\nsymbolic refs that point to other refs, like \"ref:\nrefs/heads/master\"). You should thus be able to put the sha1 of your\n(tmp) commit into refs/remotes/p4/master.\n\nYou could try that and see if git rev-list gives the expected result.\n\n> I think my understanding of merges and rebases needs more depth...and I\n> think I have mangled branches.\n>\n>\n> I tried a checkout of master and a \"git rebase remotes/p4/master\" and\n> that produced thousands of conflicts.  Was that due to my initial Linux\n> sources put in on the Perforce side?\n\nWell, when you do that, git will look back until it finds a common\nancestor commit of master and p4/master. I am guessing, that a common\nancestor for those branches does not exist in your case... If my guess\nis correct, git will go back to the beginning of master (to linux\n2.6.12-rc2) and try to apply each of those commits on top of\np4/master. Naturally, that will cause a world of pain and conflicts ;)\n\n-Tor Arvid-\n"},{"id":"150551","messageId":"4C8D3303.1030302@borg.org","threadId":"25070","inReplyTo":"AANLkTi=NGsY3wDiTLwNLpw4TJMpiSY8A=az_=v2fYDLj@mail.gmail.com","subject":"Re: git-p4","fromName":"Kent Borg","fromEmail":"kentborg@borg.org","sentAt":"2010-09-12T20:07:31Z","receivedAt":"2010-09-12T20:07:31Z","isPatch":false,"sender":{"key":"kentborg@borg.org","avatar":null},"body":"Tor Arvid Lund wrote:\n> When messing about with git-p4 I have sometimes messed up that\n> p4/master ref myself. I can normally fix it by setting it manually\n\nUm, I maybe just did that before I saw your e-mail.\n\nI edited:\n\n .git/info/refs\n .git/ORIG_HEAD\n .git/packed/refs\n\n...and put in the sha1 of the \"[git-p4:\"-commit.\n\nWhen I now do:\n\n $ git rev-list --no-merges remotes/p4/master..master\n\nI get just the one commit that I hoped to get!\n\n...did I just fix it?\n\nI don't have time to try the \"git p4 submit\" now, I am going to be late\nin meeting my wife. Tomorrow morning...will it work?\n\n\nThanks so very much for your help,\n\n-kb\n"},{"id":"150553","messageId":"AANLkTikrSt4djXep-o4Hr8EZAsiNXnqCHa2fLrys8T==@mail.gmail.com","threadId":"25070","inReplyTo":"4C8D3303.1030302@borg.org","subject":"Re: git-p4","fromName":"Tor Arvid Lund","fromEmail":"torarvid@gmail.com","sentAt":"2010-09-12T20:12:23Z","receivedAt":"2010-09-12T20:12:23Z","isPatch":false,"sender":{"key":"torarvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/439758?v=4"},"body":"2010/9/12 Kent Borg :\n> Tor Arvid Lund wrote:\n>> When messing about with git-p4 I have sometimes messed up that\n>> p4/master ref myself. I can normally fix it by setting it manually\n>\n> Um, I maybe just did that before I saw your e-mail.\n>\n> I edited:\n>\n>  .git/info/refs\n>  .git/ORIG_HEAD\n>  .git/packed/refs\n>\n> ...and put in the sha1 of the \"[git-p4:\"-commit.\n>\n> When I now do:\n>\n>  $ git rev-list --no-merges remotes/p4/master..master\n>\n> I get just the one commit that I hoped to get!\n>\n> ...did I just fix it?\n\nMy guess: Yes! :)\n\n> I don't have time to try the \"git p4 submit\" now, I am going to be late\n> in meeting my wife.  Tomorrow morning...will it work?\n\nI'm optimistic :)\n\n-TA-\n"},{"id":"150595","messageId":"4C8E33DF.7010904@borg.org","threadId":"25070","inReplyTo":"AANLkTikrSt4djXep-o4Hr8EZAsiNXnqCHa2fLrys8T==@mail.gmail.com","subject":"Re: git-p4","fromName":"Kent Borg","fromEmail":"kentborg@borg.org","sentAt":"2010-09-13T14:23:27Z","receivedAt":"2010-09-13T14:23:27Z","isPatch":false,"sender":{"key":"kentborg@borg.org","avatar":null},"body":"Tor Arvid Lund wrote:\n>> I don't have time to try the \"git p4 submit\" now, I am going to be late\n>> in meeting my wife. Tomorrow morning...will it work?\n>> \n>\n> I'm optimistic :)\n\nUm, not so great.\n\nTwo problems:\n\n - I was on the wrong branch this morning when I did the\n \"git p4 submit\" (stupid me),\n\n - I realize that even if I had done that right, part of my\n history is a big lump of Linux kernel files with no history\n but a sync out of Perforce.\n\nSo it seems what I need to do is get on a clean branch that has good\nhistory and cherry-pick all the bits I want off the branch with the bad\nancestry onto the clean branch. (And get a good \"[git-p4: depot-paths:\n...\" in place.)\n\nThen...just point p4/HEAD and p4/master and master to the newest commit\non that new clean branch. Voila!\n\nPossibly one of my last stupid questions on this: How do I do that? \n\"p4/master\" looks like a remote, but \"git remote\" doesn't seem to know\nabout it. In gitg \"master\" is green, just like a branch I might create,\nso I figure I can delete and re-create it where I want, but \"p4/master\"\nand \"p4/HEAD\" is blue. What are these blue things? How do I move them\nto a different commit?\n\nThanks,\n\n-kb\n"},{"id":"150598","messageId":"AANLkTimL3mB8LeUOANsJO7p9uwqDCN9wKnLVMTq_-=3H@mail.gmail.com","threadId":"25070","inReplyTo":"4C8E33DF.7010904@borg.org","subject":"Re: git-p4","fromName":"Tor Arvid Lund","fromEmail":"torarvid@gmail.com","sentAt":"2010-09-13T15:01:30Z","receivedAt":"2010-09-13T15:01:30Z","isPatch":false,"sender":{"key":"torarvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/439758?v=4"},"body":"On Mon, Sep 13, 2010 at 4:23 PM, Kent Borg wrote:\n> Tor Arvid Lund wrote:\n>>> I don't have time to try the \"git p4 submit\" now, I am going to be late\n>>> in meeting my wife.  Tomorrow morning...will it work?\n>>>\n>>\n>> I'm optimistic :)\n>\n> Um, not so great.\n>\n> Two problems:\n>\n>  - I was on the wrong branch this morning when I did the\n>   \"git p4 submit\" (stupid me),\n>\n>  - I realize that even if I had done that right, part of my\n>   history is a big lump of Linux kernel files with no history\n>   but a sync out of Perforce.\n\nI don't know if I understand what you mean here... If \"git diff\np4/master..\" gives output equivalent to what you would want to submit\nto p4, then that seems correct to me.\n\n> So it seems what I need to do is get on a clean branch that has good\n> history and cherry-pick all the bits I want off the branch with the bad\n> ancestry onto the clean branch.  (And get a good \"[git-p4: depot-paths:\n> ...\" in place.)\n>\n> Then...just point p4/HEAD and p4/master and master to the newest commit\n> on that new clean branch.  Voila!\n>\n> Possibly one of my last stupid questions on this: How do I do that?\n> \"p4/master\" looks like a remote, but \"git remote\" doesn't seem to know\n> about it.  In gitg \"master\" is green, just like a branch I might create,\n> so I figure I can delete and re-create it where I want, but \"p4/master\"\n> and \"p4/HEAD\" is blue.  What are these blue things?  How do I move them\n> to a different commit?\n\nWell, I don't know gitg, but I can guess that it shows branches as\nblue if they are files created inside refs/remotes/*. This is the case\nfor p4/master and p4/HEAD. They are placed there because normally,\nusers should not update these refs, nor should they directly do\ncheckouts of these branches (but your case is not exactly that\nnormal).\n\ngit remote, shows remotes as defined in your .git/config file (the\n[remote \"someremotename\"] sections). git-p4 does not need nor create\nsuch entries.\n\n-Tor Arvid-\n"},{"id":"150604","messageId":"4C8E511F.8000400@borg.org","threadId":"25070","inReplyTo":"AANLkTimL3mB8LeUOANsJO7p9uwqDCN9wKnLVMTq_-=3H@mail.gmail.com","subject":"Re: git-p4","fromName":"Kent Borg","fromEmail":"kentborg@borg.org","sentAt":"2010-09-13T16:28:15Z","receivedAt":"2010-09-13T16:28:15Z","isPatch":false,"sender":{"key":"kentborg@borg.org","avatar":null},"body":"Tor Arvid Lund wrote:\n> git remote, shows remotes as defined in your .git/config file (the\n> [remote \"someremotename\"] sections). git-p4 does not need nor create\n> such entries.\n\nI am confused trying to understand what kind of beast the p4/master is.\n\nI think my fundamental problem is that I need p4/master to point at a\nbranch with a real git history, not a sync from Perforce (which has no\ngit history).\n\nI tried pointing p4/master at a clean branch in my repository with \"git\nupdate-ref refs/remotes/p4/master ...\", but every time I tried a \"git p4\nsync --verbose\" it sprang back to pointing at the old commit (the one\nwithout a full git history). \n\nSo I figured I have brokenness I might be able to leave behind if I\ntried making a new \"git p4 clone\", doing a \"git remote add ...\" to the\nbranch I like in my old git repository, and trying it again...but I get\nthe same result. \n\nAfter my update-ref I grep in .git for the commit hash that keeps\ngrabbing my p4/master...and that hash is only in\nlogs/refs/remotes/p4/master. I do a \"git p4 sync\" and the hash\nreappears in refs/remotes/p4/master. Where is it coming from?\n\nHow do I change where p4/master points? (Put another way, how can I\nhave a complete Linux history in git but only new work in Perforce?)\n\n\nThanks,\n\n-kb, the Kent who is getting a lot smarter about git in the last few\ndays, but for whom git-p4 is not yet in control.\n"},{"id":"150633","messageId":"AANLkTingvEFDygkKipBXfCHJr2=oMQrYv3FKpxpo+TkW@mail.gmail.com","threadId":"25070","inReplyTo":"4C8E511F.8000400@borg.org","subject":"Re: git-p4","fromName":"Tor Arvid Lund","fromEmail":"torarvid@gmail.com","sentAt":"2010-09-13T21:58:08Z","receivedAt":"2010-09-13T21:58:08Z","isPatch":false,"sender":{"key":"torarvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/439758?v=4"},"body":"On Mon, Sep 13, 2010 at 6:28 PM, Kent Borg wrote:\n> Tor Arvid Lund wrote:\n>> git remote, shows remotes as defined in your .git/config file (the\n>> [remote \"someremotename\"] sections). git-p4 does not need nor create\n>> such entries.\n>\n> I am confused trying to understand what kind of beast the p4/master is.\n>\n> I think my fundamental problem is that I need p4/master to point at a\n> branch with a real git history, not a sync from Perforce (which has no\n> git history).\n\nWell, then I think you are a bit confused ;)\n\nThe p4/master branch is git's view of your p4 history. So p4/master\npoints to the most recent git/perforce commit. An important side point\nhere, is that if you have another remote (which you do in your case)\nthat is a pure git remote that knows nothing about p4, then the\np4/master branch and the origin/master branch will be disjoint.\n\n> How do I change where p4/master points?  (Put another way, how can I\n> have a complete Linux history in git but only new work in Perforce?)\n\nEhm, thinking about this some more, I wonder if this whole endeavor\nmight be continually painful...\n\nSay that you clone Linus' kernel tree with git, and that commit X is\nthe master where you will start your work.\n\nYou then import your tree at commit X into p4, and sync it back using\ngit-p4. That git-p4 sync will give you a commit X' - Such that\nchecking out X or X' will yield the same checkout tree, but they will\nhave differing commit IDs... Do you have a strategy if you:\n\n1) Commit something, Y', on top of X' in git (and syncs with p4).\n2) Someone else commits Z on top of X, which you get when you do git fetch.\n\nWhat do you do in p4? You can't be sure that it'll work to apply Z on\ntop of Y', nor the other way around...\n\nIt kind of seems like you want to have two different repositories, and\nyou want these to be equal (no one is the \"one true repository\"), and\nthis presents problems in the scenario I described above, right?\n\nI think maybe draw a few branch trees for git and p4/git-p4 and your\nown work on a good old piece of paper... It often helps to clear the\nhead and think freshly (is that a word?).\n\n-Tor Arvid-\n"},{"id":"150820","messageId":"4C920A1B.1030707@borg.org","threadId":"25070","inReplyTo":"AANLkTingvEFDygkKipBXfCHJr2=oMQrYv3FKpxpo+TkW@mail.gmail.com","subject":"Re: git-p4","fromName":"Kent Borg","fromEmail":"kentborg@borg.org","sentAt":"2010-09-16T12:14:19Z","receivedAt":"2010-09-16T12:14:19Z","isPatch":false,"sender":{"key":"kentborg@borg.org","avatar":null},"body":"Tor Arvid Lund wrote:\n> Well, then I think you are a bit confused ;)\n> \n\nThat I know is true, but I am making progress.\n\n - I have \"git p4 rebase\"-d changes from p4 world out to\n git. More than once even.\n\n - I have \"git p4 submit\"-ted changes from git back into\n p4 world. Again, more than once.\n\n - I can pull and push from/to this git repository to my primary git\nrepository.\n\n> The p4/master branch is git's view of your p4 history. So p4/master\n> points to the most recent git/perforce commit. \n\nYes.\n\n> An important side point\n> here, is that if you have another remote (which you do in your case)\n> that is a pure git remote that knows nothing about p4, then the\n> p4/master branch and the origin/master branch will be disjoint.\n> \n\nThat, I think I fixed! The first commit on the p4/master branch used to\nbe a sync from p4, but after surgery on branch references (correct\nterm?) my gateway git-p4 repository's p4/master branch now has history\nall the way back to the beginning of time in the git universe (back to\ngood ol' Linux 2.6.12-rc2). The recent commits have git-p4 comments\nthat mark the matching p4 changesets. I am not sure exactly how I did\nit, but it seems that doing a \"git-p4 rebase\" instead of \"git-p4 sync\"\nmade my surgery work.\n\nOne odd thing that had me worried was seeing the git side of the gateway\nrepository show a single history back and then show a short split\nhistory and then a single history, flopping as I ran transactions\nthrough it. I am not sure what was going on, but I think git-p4 is\ndoing an amend of the last commit to put its notes in the message, and\nif I have anything newer hanging from that commit this is a very bad\nthing. I am still worried but less so as long as I behave myself about\nnot expecting it to make amendments to anything but the newest commits.\n\nPart of the consideration is to simply be very aware of those \"[git-p4:\n...\" notes and decide where this should propagate to and design the\nworkflow accordingly. (lkml probably won't want to see p4 notations...)\n\nBut anyway, I seem to have git-p4 working in both directions, with a\ncomplete beginning-of-time history on the git side.\n\n\nTor Arvid: I owe you a beer (or whatever you drink when someone offers\nyou a beer), how often do you visit Boston?\n\n\nThanks for everyone's patience with a newbie,\n\n-kb\n"},{"id":"150825","messageId":"AANLkTik-jATT0vJagsXWfexPyKHFZ0oo7Qp95vpiqmCd@mail.gmail.com","threadId":"25070","inReplyTo":"4C920A1B.1030707@borg.org","subject":"Re: git-p4","fromName":"Tor Arvid Lund","fromEmail":"torarvid@gmail.com","sentAt":"2010-09-16T13:54:03Z","receivedAt":"2010-09-16T13:54:03Z","isPatch":false,"sender":{"key":"torarvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/439758?v=4"},"body":"On Thu, Sep 16, 2010 at 2:14 PM, Kent Borg wrote:\n> One odd thing that had me worried was seeing the git side of the gateway\n> repository show a single history back and then show a short split\n> history and then a single history, flopping as I ran transactions\n> through it.  I am not sure what was going on, but I think git-p4 is\n> doing an amend of the last commit to put its notes in the message, and\n> if I have anything newer hanging from that commit this is a very bad\n> thing.  I am still worried but less so as long as I behave myself about\n> not expecting it to make amendments to anything but the newest commits.\n\nThis is true. git-p4 does rebase (which usually rewrites history) the\nactive branch as the last step when you do git-p4 submit. So, as you\nsay, it is important to be aware of this.\n\nIf HEAD points to X, and you do git-p4 submit, then if you have\nanother branch YY on top of X, you may want to checkout YY and do git\nrebase X' (where X' is what git-p4 produces after it amends its\n[git-p4: ...] stuff).\n\n> Part of the consideration is to simply be very aware of those \"[git-p4:\n> ...\" notes and decide where this should propagate to and design the\n> workflow accordingly.  (lkml probably won't want to see p4 notations...)\n>\n> But anyway, I seem to have git-p4 working in both directions, with a\n> complete beginning-of-time history on the git side.\n\nGood stuff! Congrats :)\n\n> Tor Arvid: I owe you a beer (or whatever you drink when someone offers\n> you a beer), how often do you visit Boston?\n\nAppreciated :) Well, its been ~9 years, so maybe I should go again\nsoon :) Otherwise, say hello whenever you're in Oslo ;)\n\n-TA-\n"}]}