Date: Sat, 28 Nov 2020 22:49:27 +0000 From: Rene Ladan <rene@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: Ulrich =?iso-8859-1?Q?Sp=F6rlein?= <uqs@freebsd.org>, freebsd-git@freebsd.org Subject: Re: HEADS UP: freebsd-ports hashes were all changed Message-ID: <20201128224927.GC42737@freefall.freebsd.org> In-Reply-To: <CANCZdfon4UNwZFTKmp_Xcehge%2BvWn4NKKQOBMFakEGjE8kOCFA@mail.gmail.com> References: <X8IzeXDKyDdQCbrB@acme.spoerlein.net> <X8I54bu%2Bw/lIAxQE@acme.spoerlein.net> <20201128165115.GA22587@freefall.freebsd.org> <CANCZdfqPsjObRnNf2QN=0KmtWDHiVxUoe1zfHD_TxO1NptDkOw@mail.gmail.com> <20201128205528.GA58416@freefall.freebsd.org> <CANCZdfon4UNwZFTKmp_Xcehge%2BvWn4NKKQOBMFakEGjE8kOCFA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 28, 2020 at 02:49:44PM -0700, Warner Losh wrote:
> On Sat, Nov 28, 2020 at 1:55 PM Rene Ladan <rene@freebsd.org> wrote:
>
> > On Sat, Nov 28, 2020 at 01:41:02PM -0700, Warner Losh wrote:
> > > On Sat, Nov 28, 2020 at 9:51 AM Rene Ladan <rene@freebsd.org> wrote:
> > >
> > > > On Sat, Nov 28, 2020 at 12:52:01PM +0100, Ulrich Spörlein wrote:
> > > > > On Sat, 2020-11-28 at 12:24:41 +0100, Ulrich Spörlein wrote:
> > > > > >Hi folks, bad news
> > > > > >
> > > > > >While carving out the history of the access and mentors file (we
> > want to
> > > > > >retain that for historical analysis, which people seem to do from
> > time
> > > > > >to time), I overlooked that fact that the previous runs for ports
> > did
> > > > > >contain all of CVSROOT, but the new one, by necessity would not
> > contain
> > > > > >CVSROOT/{access,mentors}, in fact, I dropped the whole CVSROOT
> > prefix
> > > > > >from the latest rules file. It should never have been there in the
> > first
> > > > > >place. :(
> > > > > >
> > > > > >All that is to say that this of course means all the git commit
> > hashes
> > > > > >for the ports tree have changed. Oops.
> > > > > >
> > > > > >Sorry about that, please let me know if you need help in
> > transplanting
> > > > > >your work from old hashes to new hashes.
> > > > >
> > > > The web finds [1] which would translate to
> > > >
> > > > git merge orgin main --allow-unrelated-histories
> > > >
> > > > but I'm not sure if this is the correct hammer?
> > > >
> > > > [1]
> > > >
> > https://github.com/git/git/blob/master/Documentation/RelNotes/2.9.0.txt#L58-L68
> > > >
> > >
> > > I'm not sure either. What does your tree look like? Is it just tracking
> > > upstream? Or do you have changes / branches?
> > >
> > I have a few local branches for some WIP things that I keep in sync with
> > main.
> > None of those are pushed obviously. If all else fails I can just reclone
> > the
> > repository and recreate those branches, they are of a temporary nature.
> >
>
> OK. So, at this point, 'main' locally is the old hash, and 'origin/main' is
> the new hash.
>
> I'd recommend the following. What it does is creates an 'oldmain' branch to
> match the current repo, then recreates the new hash main as 'main' and then
> rebases all your WIP branches to main with the new hashes. It looks a bit
> scary, I'll grant, but I've done similar things a lot. If any is
> unfamiliar, then reading the man page first is a good idea. If things go
> wrong, then 'git reflog' will help you recover the values for old branches,
> etc. git rebase --abort is your friend if it's going horribly sideways...
>
> (1) Create a new name for the old main:
> % git checkout main
> % git checkout -b oldmain
>
> (2) Now, make main point to the new hashes
> % git checkout -B main origin/main
>
> (3) now, for each of your WIP branches, rebase them (I have -i here, but
> that's finger memory).
> % git rebase -i oldmain $WIPNAME --onto main
>
> (4) if you really want, you can now delete oldmain, though I'd keep it
> around for a while.
> % git branch -D oldmain
>
> Make sense? Oh, if it does go terribly sideways, and you need to just
> reclone into a new directory, you can check out
> http://bsdimp.blogspot.com/2020/08/how-to-transport-branch-from-one-git.html
> which will show you how to use git format-patch and git am to move the
> branches to the new repo. Again, git reflog can help if branch names get
> screwed up since that's as close as git gets to keeping meta-data history...
>
> And please let me know if it works, or if you encounter any issues.
>
Ah, I read over step 2, and using the --allow-unrelated-histories flag has
now created a local main that is 546215 commits ahead of origin/main :(
Time to redo that step.
René
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201128224927.GC42737>