Simon Marlow: > On 24/05/2011 05:59, Manuel M T Chakravarty wrote: >> Simon Marlow: >>> On 12/05/2011 16:40, Simon Peyton-Jones wrote: >>>> As I understand it, the moment you share a repo, you can't rebase >>>> any more. I'd be delighted to learn otherwise. >>> >>> Perhaps pedantry, but this might help clear things up a bit: the >>> moment you share a *commit*, you can't rebase it any more. >> >> Yes, but I believe, we need to define the meaning of *sharing* in >> this context. I think it is fine to rebase a commit that was shared >> between a small team of people working on a particular new feature. >> in contrast, a commit that was shared with the larger community may >> not be rebased anymore. This distinction is important as otherwise >> commits bounced between two developers working in close cooperation >> could not be rebased anymore, which would not be what we want IMHO. >> >> Given this, you could require that those small teams use their own >> git repos (say on GitHub) to share their not-yet-public commits. >> However, the GHC community seems to collaborate via c.h.o, so I think >> it makes sense to regard some branches (eg, the current ghc-generics >> branch) as "private" development branches. Only when commits from >> those branches make it into the master or onto stable branches should >> they be regarded as being public. > > Yes, I'm fine with a group of developers working on the same branch agreeing > to rebase from time to time. Is there an established protocol for doing > this? How do you tell any users who might be following the branch but aren't > involved in development? The safe thing to do seems to be to start a new > branch, but somehow I think that isn't what normally happens.
I agree that the safe thing is to start a new branch. Otherwise, maybe an email to the dev list could announce a rebase. (Users who follow experimental in-flight dev branches can be expected to follow the dev list IMHO.) If we agree that the procedure that you outlined and the details that we discussed in this thread are going into the direction of the policy that we would like to adopt, I'd be happy to summarise the email thread on a wiki page. We can always evolve the policy over time as we gain more experience with git. Manuel _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
