History rewrite for corebase and gui

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

History rewrite for corebase and gui

Ivan Vučica-2
Hi,

https://github.com/gnustep/gitsvn-scripts/issues/2

"""
I've mistakenly created merges which work okay with local clients, but
confuse Github and other web UIs which don't recognize replace refs.

- gnustep/libs-gui@250d3ee0af7f2fc304ab735ada8b3238154d060f
- gnustep/libs-gui@44dd9abab7db1aa3e0d41f2b7da55c788f795c8f
- gnustep/libs-corebase@4d4fa0a5a38ff6fa4b529216d3cc3859765d9cbf

This will require rewriting history, but it's better in the long run.
"""

I've just pushed rewritten libs-corebase (where I cherrypicked the
contributions instead).

I'm about to do the same for libs-gui.

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
# 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.

Thankfully you should be prevented from pushing if you don't do this correctly.

You can also store your unsubmitted patches for safekeeping by using
git format-patch correctly. Since I haven't used this much, how to do
this correctly is also out of scope and can be found online.

Sorry about this, but I messed up pretty badly doing these merges, so
we ended up with doubled history in any client that doesn't recognize
/ doesn't have replace refs downloaded.

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: History rewrite for corebase and gui

Ivan Vučica-2
This is now complete.

On Tue, Jun 20, 2017 at 9:10 PM, Ivan Vučica <[hidden email]> wrote:

> Hi,
>
> https://github.com/gnustep/gitsvn-scripts/issues/2
>
> """
> I've mistakenly created merges which work okay with local clients, but
> confuse Github and other web UIs which don't recognize replace refs.
>
> - gnustep/libs-gui@250d3ee0af7f2fc304ab735ada8b3238154d060f
> - gnustep/libs-gui@44dd9abab7db1aa3e0d41f2b7da55c788f795c8f
> - gnustep/libs-corebase@4d4fa0a5a38ff6fa4b529216d3cc3859765d9cbf
>
> This will require rewriting history, but it's better in the long run.
> """
>
> I've just pushed rewritten libs-corebase (where I cherrypicked the
> contributions instead).
>
> I'm about to do the same for libs-gui.
>
> 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
> # 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.
>
> Thankfully you should be prevented from pushing if you don't do this correctly.
>
> You can also store your unsubmitted patches for safekeeping by using
> git format-patch correctly. Since I haven't used this much, how to do
> this correctly is also out of scope and can be found online.
>
> Sorry about this, but I messed up pretty badly doing these merges, so
> we ended up with doubled history in any client that doesn't recognize
> / doesn't have replace refs downloaded.

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: History rewrite for corebase and gui

Derek Fawcus-2
In reply to this post by Ivan Vučica-2
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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev