Date: Sun, 8 Nov 2015 07:00:49 -0800 From: David Chisnall <theraven@FreeBSD.org> To: =?utf-8?Q?Ulrich_Sp=C3=B6rlein?= <uqs@FreeBSD.org> Cc: Alfred Perlstein <alfred@freebsd.org>, freebsd-git@freebsd.org, freebsd-current@freebsd.org, git-admin@freebsd.org Subject: Re: FYI: SVN to GIT converter currently broken, github is falling behind Message-ID: <AA0D183E-411E-41C5-AA7A-2B91D3790B20@FreeBSD.org> In-Reply-To: <CAJ9axoQmgT0B23UtmzGeMcvS%2BCHxC16FL53fPGObBZoxEC03aQ@mail.gmail.com> References: <CAJ9axoTuuBt4%2Bg4o1%2BLy9VmNfAa3pcMhcPr2ws8T1kCm=Om=tg@mail.gmail.com> <CAJ9axoRBcFD=-d=pzJJvYempEO-EyR_kAiK3EZQ_hp%2B7_J1iyQ@mail.gmail.com> <563EAAB8.5020702@freebsd.org> <CAJ9axoQmgT0B23UtmzGeMcvS%2BCHxC16FL53fPGObBZoxEC03aQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8 Nov 2015, at 02:32, Ulrich Sp=C3=B6rlein <uqs@FreeBSD.org> wrote: >=20 >=20 > Git commit hashes *might* change in the future. I really don't > see how this is a big deal anyway. It happened once and I'm trying to > have it never happen again. But why are people afraid of this > happening? Every "official" git commit is tagged with a SVN revision > and the contents of those revisions are obviously correct (just not > the ancestry and the commit objects, possibly). So it would be easy to > write a script that replays VendorA's git history and swaps out the > new official commits for the old official commits. There would be no > merge conflicts. Git commit hashes must not change, or we completely destroy the utility = of the git mirror for all downstream users. You can no longer do a = merge from upstream git if the hashes in your local clone do not match = the hashes downstream. Your answer of expecting every downstream user = of FreeBSD=E2=80=99s git repo (GitHub tracks over 600 of them, there are = likely more that are using private clones) to write a script to fix the = mess for themselves is completely unacceptable. If there has been a window in which incorrect hashes were generated, = this can be fixed by moving that to a branch, doing the correct thing in = master, and then using git-imerge in rebase-with-history mode. After = the point of the fix, there will be a single set of commits, but before = that there will be two options as parents, one for each version of the = export. Please remember that a guarantee of not changing the hashes of the = history was one of the conditions that Core had for promoting this to an = official FreeBSD service. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AA0D183E-411E-41C5-AA7A-2B91D3790B20>