On Wed, Jul 20, 2016 at 7:44 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > 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. When treating the SHA1 version as a foreign dvcs and the SHA256 as the real deal, we could introduce "pointer objects", and during the conversion create a 4e55ed3 pointer that points to the SHA256 commit of (add: add --chmod=+x / --chmod=-x options, 2016-05-31). Ideally we would not even expose this sort of object a lot, e.g. git show <pointer> would just redirect automatically. Instead of a new class of "pointer objects" we could also solve this via a lot of refs. (refs/old-sha1/4e55ed3 pointing to the converted commit; Though we would need to accept partial refs names then :/) > -- > 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 -- 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