Re: History rewrite for corebase and gui

[Derek Fawcus]

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