Simon Marlow: > On 12/05/2011 16:40, Simon Peyton-Jones wrote: >> | I think what SimonM described in the recent thread is basically what we >> want: >> | >> | - you develop in your working tree and commit patches there. At >> | this point it's completely safe to rebase - the patches are only >> | in one place. >> >> I don't think so. Like I say, the branch is shared between several >> collaborators. Each is modifying branch. Each is merging in changes >> from the other. Each is (occasionally, to be sure) merging changes >> from the HEAD). > > I was talking about development on the master branch when I made that comment > that Manuel quoted above, but the idea does apply to shared development > branches too. The idea is just this: > > When you have a set of commits that you have not yet > pushed (or pulled) anywhere else, you can rebase them > to eliminate merge patches before pushing. > > That applies to shared development branches as well as the master branch. > > I'm not saying anyone has to do this if they aren't comfortable with using > rebase, but it does help reduce the noise on the list and clean up the > history. > >> 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. Manuel _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
