On Thu, May 31, 2012 at 07:13:42PM +0000, Robin H. Johnson wrote: > - You have a commit, that you want to put into the Gentoo tree. > - You have already pushed it to your github, signed
If I have a github tree, that would probably be because I didn't have push access to the official tree, so signing the commit probably isn'tgoing to matter; I would expect that a gentoo dev who has push access to the tree would sign the commit when it is put into the gentoo tree. > - It needs to be merged/rebased so that it applies on the Gentoo tree. > - If you force it to be a rebase so it applies on the tip, then you may > have changed the history of your github tree, and broken any further > forks. > - If you permit a merge instead, nobody gets broken. If you do this: git rebase master mybranch git checkout master git merge mybranch <-- this is a fast-forward merge git pull --rebase git push I think that covers this concern doesn't it? > > > 2. > > > Git-SVN breakage. Why does this matter you're wondering? > > > We need the newer Git for the commit signing, but it comes with a > > > price, the git-svn binary has some major failures with SVN 1.7. > > > Git since 1.7.8 has been broken this way. > > To clarify - these won't be issues for gentoo per se, but there is a > > sense that we can't stabilize the latest git because it will break it > > for people using git-svn on non-gentoo work? > As the Git maintainer, I will not keyword it for anybody until I know > it's not going to lose/corrupt data, regardless of what they are using > it for. Why not keyword it and use package.use.mask for the git-svn flag? William
pgpwkzFYxv1GM.pgp
Description: PGP signature
