This is now complete. On Tue, Jun 20, 2017 at 9:10 PM, Ivan Vučica <i...@vucica.net> 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 Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev