On Wed, 25 May 2016, Mark Adams wrote: > Is rebase -i going to work? I read: > > git rebase -i master > > Note that rebasing to the master does not work if you merged the master > into your feature branch while you were working on the new feature. If you > did this you will need to find the original branch point and call git > rebase with a SHA1 revision.
You've already pointed out the problem with 'rebase -i master' I would do 'rebase master' and 'rebase -i commitid' separately - and not club them into a single operation. Perhaps 'rebase master && rebase -i master' is what you would like to do [and should workarround the above issue]. And with any rebase - one would always have to be careful - and verify exactly whats hapenning [and if its consistant with what you expect or not] > So I was pulling from master all the time, by mistake. If I do a rebase -i > with /jed/mark/snes-ex56c, will it give me all of the branch to squash? This question does not make sense to me. If you want to set 'mark/snes-ex56c' to the jed's 'rebased' branch - you can do: git co mark/snes-ex56c git reset --hard origin/jed/mark/snes-ex56c [and then I would use rebase - to rebase against master or squash/modify commits - as needed] and then delete all the un-needed branches. git push -u origin :mark/snes-ex56b git push -u origin :jed/mark/snes-ex56c Mark - perhaps its best if you are not an integrator - and always go through PR process - so that someone [usually Barry, Jed, Matt] can verify any issues - before feture branches are merged to maint/master/next? Thanks, Satish
