On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > But that strategy *still* ignores the distributed nature of Git. Just > because *you* make that merge at a certain point does not necessarily mean > that I make it at that point, too. > > Any approach that tries to have one single point of conversion will most > likely fall short of a solution. OK I see the difference in our views now. To me an sha256 repo would see an sha1 repo as a _foreign_ DVCS, pretty much like git sees mercurial now. So a transition from sha1 to sha256 is not that different from cvs -> svn -> a dvcs bubble -> git. > To be honest, I am less concerned about the GPG-signed commits (after all, > after switching to a more secure hash algorithm, a maintainer could > cross-sign all signed commits, or only the branch tips or tags, as new > tags, to reinstitute trust). > > I am much more concerned about references to commits, both inside and > outside the repository. That is, if I read anywhere on the internet about > Git having added support for `git add --chmod=+x <file>` in 4e55ed3 (add: > add --chmod=+x / --chmod=-x options, 2016-05-31), I want to find that > commit by that reference. > > And I am of course concerned what should happen if a user wants to fetch > from, or push to, a SHA-1-hashed remote repository into, or from, a > SHA-256-hashed local one. to follow the above, in my view, interaction with sha1 repos go through some conversion bridges like what we have with hg and svn. I don't know if we are going this route. It's certainly simpler and people already have experiences (from previous migration) to prepare for it. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html