On 8 Nov 2015, at 02:32, Ulrich Spörlein <u...@freebsd.org> wrote: > > > 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’s 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 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
