{"thread":{"id":"30214","subject":"git p4: any way to avoid rebasing all the time?","startedAt":"2012-04-11T16:27:59Z","lastAt":"2012-04-18T11:53:01Z","messageCount":3,"participants":["Luke Diamand","Vitor Antunes","Pete Wyckoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"188984","messageId":"CAE5ih7_Fh0XA-XNNvtHnXhYwUvwmmg-Z+y-Mb5Wvra3Y83eFsw@mail.gmail.com","threadId":"30214","inReplyTo":null,"subject":"git p4: any way to avoid rebasing all the time?","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2012-04-11T16:27:59Z","receivedAt":"2012-04-11T16:27:59Z","isPatch":false,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"Is there a way to get \"git p4\" to not rebase all the time?\n\nRight now, git commits get discarded and replaced with new ones with\nthe same contents and extra git-p4 metadata embedded in the comment.\n\nIf we put this git-p4 metadata into a git note then we would not need\nto rewrite the commits, and so could perhaps avoid rebasing quite so\nmuch.\n\nHowever, if \"git p4\" won't rewrite commits, then it can't reorder them\nto match the ordering seen from p4.\n\nSo you could end up with git users seeing OLDHEAD,G,P and p4 users\nseeing OLDHEAD,P,G, as there's a race to see who submits against\nOLDHEAD first, which p4 always wins.\n\nWould this matter (assuming the git and p4 commits are all reasonably\nindependent) or is there a way to avoid it?\n\nPerhaps hook into the pre-receive hook? If the newest p4 changelist is\nnot the same as the HEAD of the branch being pushed to, then reject\nthe push, just as would happen if the branch could not be\nfast-forwarded in a normal git repo? (Even with this there is still a\nsmall window of opportunity).\n\nAt that point, the \"git p4 rebase\" command would still be used, but\nwould normally be a no-op.\n\nOr would that result in something far too complicated to have any\nchance of working?\n\nThanks,\nLuke\n"},{"id":"189000","messageId":"CAOpHH-Ufa7m8rEe+CTEGo-ChLOfFgyBkeiWrP92Sv=VLKgVmZA@mail.gmail.com","threadId":"30214","inReplyTo":"CAE5ih7_Fh0XA-XNNvtHnXhYwUvwmmg-Z+y-Mb5Wvra3Y83eFsw@mail.gmail.com","subject":"Re: git p4: any way to avoid rebasing all the time?","fromName":"Vitor Antunes","fromEmail":"vitor.hda@gmail.com","sentAt":"2012-04-11T17:22:59Z","receivedAt":"2012-04-11T17:22:59Z","isPatch":false,"sender":{"key":"vitor.hda@gmail.com","avatar":"https://avatars.githubusercontent.com/u/606876?v=4"},"body":"On Wed, Apr 11, 2012 at 5:27 PM, Luke Diamand wrote:\n> Is there a way to get \"git p4\" to not rebase all the time?\n>\n> Right now, git commits get discarded and replaced with new ones with\n> the same contents and extra git-p4 metadata embedded in the comment.\n>\n> If we put this git-p4 metadata into a git note then we would not need\n> to rewrite the commits, and so could perhaps avoid rebasing quite so\n> much.\n>\n> However, if \"git p4\" won't rewrite commits, then it can't reorder them\n> to match the ordering seen from p4.\n>\n> So you could end up with git users seeing OLDHEAD,G,P and p4 users\n> seeing OLDHEAD,P,G, as there's a race to see who submits against\n> OLDHEAD first, which p4 always wins.\n>\n> Would this matter (assuming the git and p4 commits are all reasonably\n> independent) or is there a way to avoid it?\n>\n> Perhaps hook into the pre-receive hook? If the newest p4 changelist is\n> not the same as the HEAD of the branch being pushed to, then reject\n> the push, just as would happen if the branch could not be\n> fast-forwarded in a normal git repo? (Even with this there is still a\n> small window of opportunity).\n>\n> At that point, the \"git p4 rebase\" command would still be used, but\n> would normally be a no-op.\n>\n> Or would that result in something far too complicated to have any\n> chance of working?\n>\n> Thanks,\n> Luke\n\nHi Luke,\n\nThis guy modified git-p4 to store information in notes:\n\nhttps://github.com/ermshiperete/git-p4\n\nCould you see if his implementation would fit your requirements?\n\nVitor\n"},{"id":"189622","messageId":"20120418115301.GA24716@padd.com","threadId":"30214","inReplyTo":"CAE5ih7_Fh0XA-XNNvtHnXhYwUvwmmg-Z+y-Mb5Wvra3Y83eFsw@mail.gmail.com","subject":"Re: git p4: any way to avoid rebasing all the time?","fromName":"Pete Wyckoff","fromEmail":"pw@padd.com","sentAt":"2012-04-18T11:53:01Z","receivedAt":"2012-04-18T11:53:01Z","isPatch":false,"sender":{"key":"pw@padd.com","avatar":null},"body":"luke@diamand.org wrote on Wed, 11 Apr 2012 18:27 +0200:\n> Is there a way to get \"git p4\" to not rebase all the time?\n> \n> Right now, git commits get discarded and replaced with new ones with\n> the same contents and extra git-p4 metadata embedded in the comment.\n> \n> If we put this git-p4 metadata into a git note then we would not need\n> to rewrite the commits, and so could perhaps avoid rebasing quite so\n> much.\n\nI don't know if it is always true that the change that went from\ngit to p4 and back is identical to the original git commit.\nThings like timestamp and maybe author name? We have evil\nsystems that rewrite p4 change descriptions post submit, worse\nyet.\n\nYou can do funny merges to make it look like you're not rebasing:\n\n o--o--o p4/master\n \\\n A--B top\n\nsubmit:\n\n o--o--o--A'--B' p4/master\n \\\n A--B top\n\nmerge -s ours, so that M == B' == B.\n\n o--o--o--A'--B' p4/master\n \\ \\\n A--B---M top\n\nThe merge changes nothing, but avoids a rebase for anything that\ndepended on the original A and B.\n\n> However, if \"git p4\" won't rewrite commits, then it can't reorder them\n> to match the ordering seen from p4.\n> \n> So you could end up with git users seeing OLDHEAD,G,P and p4 users\n> seeing OLDHEAD,P,G, as there's a race to see who submits against\n> OLDHEAD first, which p4 always wins.\n> \n> Would this matter (assuming the git and p4 commits are all reasonably\n> independent) or is there a way to avoid it?\n> \n> Perhaps hook into the pre-receive hook? If the newest p4 changelist is\n> not the same as the HEAD of the branch being pushed to, then reject\n> the push, just as would happen if the branch could not be\n> fast-forwarded in a normal git repo? (Even with this there is still a\n> small window of opportunity).\n\nYes, the race issues are tough. There is no way in p4 to ensure\na given existing ancestor when submitting. Closest you can come\nis with locking, which is sometimes annoying to other users:\n\n p4 lock //depot/path/...\n \n p4 submit\n p4 unlock //depot/path/...\n\nYou can lock just the files being submitted, but that doesn't\nprevent other non-intersecting changes from sneaking in.\n\nIf there is a series of git commits, they can be checked in\natomically on a side branch in p4, and merged. That doesn't help\nyour rebase issue, but is a way to keep a series of changes from\nbeing broken up by races at p4.\n\n -- Pete\n\n> At that point, the \"git p4 rebase\" command would still be used, but\n> would normally be a no-op.\n> \n> Or would that result in something far too complicated to have any\n> chance of working?\n"}]}