Hi everyone, At the dev meeting today we talked about this issue at length and came to some conclusions.
First, what I was really trying to achieve by rebasing and squashing was a history where I knew that the committer intended the code to be stable. When we work in our branches there are many times where we intentionally commit code that is broken. I wanted this history to make my life easier if I needed to track down where a bug was introduced into the code base. Looking through branch commits would be distracting and a lot more difficult. We decided: 1. When we push upstream we do so with care. This will give us the 'black line' of commits where we expect the code base to be in good order. 2. Our community continues to be the open and safe place we've always been - there is no judgement of working process and interim commits. If someone does a pull request and we like the final commit, we merge their branch in and push it upstream. The merge 'dot' will be the one that appears on the black line and the stable point that we care about. 3. If we ever get something offensive in a commit (this has never happened so far) then we'll deal with that specially and make a patch for the code we want in the repository. 4. We recommend that people keep the history of their working process but if someone wants to rebase their own branch before doing a pull request we are fine with that. Thanks everyone for contributing to the conversation! Michelle _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
