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
> - 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
> - 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
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?