: 1) git merge (no fast forward) : : This creates a single merge commit that points to two parents -- the
It may only create a single commit, but from the perspective of people viewing master, it "adds" every commit that was on the jira/SOLR-445 branch to the master branch -- generating an metric ass-ton of emails among other things, but more importantly it pollutes history with a lot of intermediate crap... : All of the above are useful, depends on the situation. A single : "squashed" commit is simpler to port across to other branches (it's a : single "patch" after all). It also helps to drop the noisy changes : that possibly happened during development (nocommits, intermediate : refactorings, etc.), leaving only the "clean" feature patch. yeah ... basically exactly what i want ... this keeps master and branch_6x cleaner for things like git bisect, and doesn't "lose" any historical info about decisions made because they will still be viewable in jira/SOLR-445 (and mirrors how we would do land patches or do branch merges with svn) : On the other hand, if the feature branch is long-lived and you want to : merge more than once (for some reason), you're better off with a : regular merge (because then subsequent merges would only apply : differential commits). Yep -- not something i am particularly worried about. Thanks Dawid: i mainly just wnated to make sure i hadn't missed a memo somewhere that said "This is the prefered/recommended/required way to land feature branches in the lucene git model" -Hoss http://www.lucidworks.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
