On Thu, May 31, 2012 at 12:49 PM, Robin H. Johnson <robb...@gentoo.org> wrote: > 1. > Discussion on merge policy. Originally I thought we would disallow merge > commits, so that we would get a cleaner history. However, it turns out that if > the repo ends up being pushed to different places with slightly different > histories, merges are absolutely going to be required to prevent somebody from > having to rebase at least one of their sets of commits that are already > pushed.
Not sure I'm following, but I will be the first to admit that I'm a git novice. Would this be aided by a convention, like only committing to master on the gentoo official repository, and any on-the-side work on places like github/etc stays in branches? Those repositories would just keep getting fed commits on master from the official repository. > > 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? I think the general conclusion was that we would not be supporting any mixed git+cvs/svn/etc workflows for gentoo itself. If that is the case, what is our sense of how important this feature even is to gentoo developers? They're the only ones who really have to have the latest git to commit to the official tree. Rich
