threads / discuss / 30214

git p4: any way to avoid rebasing all the time?

Subject: git p4: any way to avoid rebasing all the time?

## tl;dr

3 messages between Apr 11, 2012 and Apr 18, 2012.

replies: 2people: 3as markdown or json

Luke Diamand· Apr 11, 2012, 16:27 UTC · lore

Is there a way to get "git p4" to not rebase all the time?

Right now, git commits get discarded and replaced with new ones with the same contents and extra git-p4 metadata embedded in the comment.

If we put this git-p4 metadata into a git note then we would not need to rewrite the commits, and so could perhaps avoid rebasing quite so much.

However, if "git p4" won't rewrite commits, then it can't reorder them to match the ordering seen from p4.

So you could end up with git users seeing OLDHEAD,G,P and p4 users seeing OLDHEAD,P,G, as there's a race to see who submits against OLDHEAD first, which p4 always wins.

Would this matter (assuming the git and p4 commits are all reasonably independent) or is there a way to avoid it?

Perhaps hook into the pre-receive hook? If the newest p4 changelist is not the same as the HEAD of the branch being pushed to, then reject the push, just as would happen if the branch could not be fast-forwarded in a normal git repo? (Even with this there is still a small window of opportunity).

At that point, the "git p4 rebase" command would still be used, but would normally be a no-op.

Or would that result in something far too complicated to have any chance of working?

Thanks, Luke

Vitor Antunes· Apr 11, 2012, 17:22 UTC · re: Luke Diamand · lore

Re: git p4: any way to avoid rebasing all the time?

On Wed, Apr 11, 2012 at 5:27 PM, Luke Diamand <luke@diamand.org> wrote:

Show 33 quoted lines

> Is there a way to get "git p4" to not rebase all the time?
>
> Right now, git commits get discarded and replaced with new ones with
> the same contents and extra git-p4 metadata embedded in the comment.
>
> If we put this git-p4 metadata into a git note then we would not need
> to rewrite the commits, and so could perhaps avoid rebasing quite so
> much.
>
> However, if "git p4" won't rewrite commits, then it can't reorder them
> to match the ordering seen from p4.
>
> So you could end up with git users seeing OLDHEAD,G,P and p4 users
> seeing OLDHEAD,P,G, as there's a race to see who submits against
> OLDHEAD first, which p4 always wins.
>
> Would this matter (assuming the git and p4 commits are all reasonably
> independent) or is there a way to avoid it?
>
> Perhaps hook into the pre-receive hook? If the newest p4 changelist is
> not the same as the HEAD of the branch being pushed to, then reject
> the push, just as would happen if the branch could not be
> fast-forwarded in a normal git repo? (Even with this there is still a
> small window of opportunity).
>
> At that point, the "git p4 rebase" command would still be used, but
> would normally be a no-op.
>
> Or would that result in something far too complicated to have any
> chance of working?
>
> Thanks,
> Luke

Hi Luke,

This guy modified git-p4 to store information in notes:

https://github.com/ermshiperete/git-p4

Could you see if his implementation would fit your requirements?

Vitor

Pete Wyckoff· Apr 18, 2012, 11:53 UTC · re: Luke Diamand · lore

Re: git p4: any way to avoid rebasing all the time?

luke@diamand.org wrote on Wed, 11 Apr 2012 18:27 +0200:

Show 8 quoted lines

> Is there a way to get "git p4" to not rebase all the time?
> 
> Right now, git commits get discarded and replaced with new ones with
> the same contents and extra git-p4 metadata embedded in the comment.
> 
> If we put this git-p4 metadata into a git note then we would not need
> to rewrite the commits, and so could perhaps avoid rebasing quite so
> much.

I don't know if it is always true that the change that went from git to p4 and back is identical to the original git commit. Things like timestamp and maybe author name? We have evil systems that rewrite p4 change descriptions post submit, worse yet.

You can do funny merges to make it look like you're not rebasing:

  o--o--o   p4/master
         \
          A--B   top

submit:

  o--o--o--A'--B'  p4/master
         \
          A--B   top

merge -s ours, so that M == B' == B.

  o--o--o--A'--B'  p4/master
         \      \
          A--B---M  top

The merge changes nothing, but avoids a rebase for anything that depended on the original A and B.

Show 15 quoted lines

> However, if "git p4" won't rewrite commits, then it can't reorder them
> to match the ordering seen from p4.
> 
> So you could end up with git users seeing OLDHEAD,G,P and p4 users
> seeing OLDHEAD,P,G, as there's a race to see who submits against
> OLDHEAD first, which p4 always wins.
> 
> Would this matter (assuming the git and p4 commits are all reasonably
> independent) or is there a way to avoid it?
> 
> Perhaps hook into the pre-receive hook? If the newest p4 changelist is
> not the same as the HEAD of the branch being pushed to, then reject
> the push, just as would happen if the branch could not be
> fast-forwarded in a normal git repo? (Even with this there is still a
> small window of opportunity).

Yes, the race issues are tough. There is no way in p4 to ensure a given existing ancestor when submitting. Closest you can come is with locking, which is sometimes annoying to other users:

    p4 lock //depot/path/...
    <verify same change number>
    p4 submit
    p4 unlock //depot/path/...

You can lock just the files being submitted, but that doesn't prevent other non-intersecting changes from sneaking in.

If there is a series of git commits, they can be checked in atomically on a side branch in p4, and merged. That doesn't help your rebase issue, but is a way to keep a series of changes from being broken up by races at p4.

                -- Pete

Show 5 quoted lines

> At that point, the "git p4 rebase" command would still be used, but
> would normally be a no-op.
> 
> Or would that result in something far too complicated to have any
> chance of working?