On Tue, Oct 12, 2010 at 9:47 AM, David Cournapeau <[email protected]> wrote: >> Now might be a good time to discuss how we'd like the history to look >> in a year from now. If we follow the above approach, I guess we may >> end up with one merge message for each small little bug-fix? (Unless >> --rebase is used) How do we ensure that "fast-forward" merges occur >> whenever possible? > > The only solution that I know of is to have a pull-like workflow, but > I thought this was rejected as too complicated ?
My approach is normally to: - Never merge the master branch into my development branches - Create a branch with a clean patch history before merging back into master - Then: merge into master, getting a fast-forward merge if possible - Push back to github When I have large changes that consist of several commits on a single topic, I normally explicitly ask for a non-fast-forward merge, so that the history is not contaminated by a whole slew of commit messages. Regards Stéfan _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
