On 16 Aug 2014, at 12:55 pm, Andrea Pescetti <pesce...@apache.org> wrote:
> I've also been fixing (or breaking, who knows!) some documentation on my > clone (my "fork" as Github likes to call it) but I'll submit a pull request > only when basic things work. I've just merged in your changes and also invited you as a committer to the repository. Then you'll be able to push directly to it instead of having to maintain your own fork. I vote that we establish a policy of rebasing instead of merging in the general case (unless there's a good reason to do otherwise), as this will help maintain a mostly-linear history and avoid the annoyances described in [1]. That is, if before I push to the repository I see that the remote master has advanced (due to you or Jan committing something else), I'll rebase my commits on top of yours, so they look like they come "after" them in the history. Likewise, you and Jan would do the same if I've made commits. What do you think? http://blog.spreedly.com/2014/06/24/merge-pull-request-considered-harmful -- Dr. Peter M. Kelly Founder, UX Productivity pe...@uxproductivity.com http://www.uxproductivity.com/ http://www.kellypmk.net/ PGP key: http://www.kellypmk.net/pgp-key (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
signature.asc
Description: Message signed with OpenPGP using GPGMail
