开发者

Forcing a Git rebase

开发者 https://www.devze.com 2023-03-23 16:44 出处:网络
Use case: Three git clones of the same repository A, B, B2. Repos A and B are normal, B2 is naked (made with --bare). All under my control, i.e. there is only one user.

Use case: Three git clones of the same repository A, B, B2. Repos A and B are normal, B2 is naked (made with --bare). All under my control, i.e. there is only one user.

On site B, I do work (several git commits), then git push B2.

  • On site A, git pull B2.
  • On site A, git rebase -i xx..HEAD to squash some commits and clean history (a great command).
  • Q: How to communicate the result to site B?

I can do:

But this is not quite right. The site B working directory will have a strange history after a git pull B2.

I need some way to not use --force. I'd like to throw away xx..HEAD on B2, then push normally from A. Perhaps:

On B2 (the naked repo)

  • git reset --hard xx

Not sure that is enough. I can do it by re-cloning from site A (delete B2, git init --bare, push from A), but that seems like overkill. The How to push/pull Git rebase post seems relevant, but I'm hoping for some answer besides "don't do this".

Bottom line, how do I truly and completely throw away commits on B2 so the rebased history from A will be accepted as new commits?


 git reset --hard 

throws away commits just in the sense in which you want them to be thrown away.


I need some way to not use --force. I'd like to throw away xx..HEAD on B2, then push normally from A.

Um, throwing away xx..HEAD on B2, then pushing normally from A is pretty much the exact definition of --force. Just use --force again when pulling to B and you'll be okay, as long as you rebase any branches in B back to commit xx or earlier before pulling.

0

精彩评论

暂无评论...
验证码 换一张
取 消