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 

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 


freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to