+1. Even if the patch is coming from my local branch, I usually do a patch + commit rather than a merge.
Enis On Fri, May 23, 2014 at 12:07 PM, Konstantin Boudnik <[email protected]> wrote: > +1 > > In the interest of full disclosure, the only good excuse for non > fast-forward > commit messages is when you are merging a significant chunk of a code back > into the master, e.g. with feature development, hot fixes, releases, etc. > In > such a case having an extra piece of historical reference might be helpful > (see http://nvie.com/posts/a-successful-git-branching-model/ as a pretty > good > outline). > > Cos > > On Fri, May 23, 2014 at 10:38AM, Andrew Purtell wrote: > > I recommend we do not push merge commits upstream. I suppose it is easy > > enough to filter them out when looking at history but there is no need to > > be merging upstream branches into your local tracking branch when you can > > rebase instead. In this way we can avoid polluting the history in the > > master repository with unnecessary merge commit entries. (And maybe some > > devs will be merging upstream into tracking branches or merging commits > > from local feature branches several times per day, and these will all > > accumulate...) > > > > When updating your local tracking branch from upstream, use git fetch > > upstream && git rebase upstream/branch instead of 'git merge'. > > > > When developing features on a local branch it's possible to do a squash > > commit from the feature branch to the tracking branch using 'git rebase' > > instead of 'git merge', then a push of the single squashed commit from > the > > tracking branch to the upstream branch. > > > > If these workflow choices are acceptable by consensus we can update the > > 'how to commit' document with an illustration of the workflow with > example > > commands. > > > > > > -- > > Best regards, > > > > - Andy > > > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > > (via Tom White) >
