HEADS UP: freebsd-ports hashes were all changed

[Oliver Pinter]

On Saturday, November 28, 2020, Warner Losh <imp at bsdimp.com> wrote:

> On Sat, Nov 28, 2020 at 1:55 PM Rene Ladan <rene at 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 at 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,


Another trick will be to create tags for the branches. Tags are cheap in
git, reflog have a limited history by default AFAIK.


> 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.
>
> Warner
> _______________________________________________
> freebsd-git at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-git
> To unsubscribe, send any mail to "freebsd-git-unsubscribe at freebsd.org"
>