On Tue, Jun 20, 2017 at 09:10:43PM +0100, Ivan Vu??ica wrote: > You *will* need to cherrypick (or rebase, though I have less faith > that this will work) if you have changes locally. I suggest > cherrypick. Exact procedure for how to do this is unfortunately out of > scope for this mail, but basically this should work: > > git log # and note commit hashes for each of your changes > git checkout origin/master > git cherry-pick CHANGE1 > git cherry-pick CHANGE2
One can also do it as 'git cherry-pick CHANGE1 CHANGE2' etc. Rebase is just automating the above, with an easy way to fixup unclean merges. Assuming 'my-changes' had your new stuff, and 'cut-point' was a ref laid on the commit before the first one you want to move, then the following would also work: git rebase --onto origin/master cut-point my-changes Any concerns about doing it wrong can be mitigated by first laying a new branch over the work, and rebasing that instead. i.e. in the above example with: git branch my-changes-to-rebase my-changes git rebase --onto origin/master cut-point my-changes-to-rebase After which 'my-changes-to-rebase' should have the rebased content, and 'my-changes' still points to the original reference before rebase. At which point one can simply delete 'my-changes' and rename 'my-changes-to-rebase' to 'my-changes' (git branch -D ; git branch -m). Then if one does enter the wrong set of refs, one simply deletes the rebased new branch, and starts again, this time with the correct references. > # etc > git log # and note commit hash of the new head > echo "your-new-commit-hash-here" > .git/refs/heads/master # I don't > know how else to change what the 'master' local branch points to, and > this works for me. git checkout master; git reset --hard HASH or simply use 'git update-ref', see 'git help update-ref'. (but then I'm lazy and occasionally use the echo approach as well). DF _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev