> ...because, unless i'm missing something, if i don't use --squash then every > intermediate commit to branch jira/SOLR-445 will be replayed on master
I think it's best explained in terms of patches and single commits, Chris. 1) git merge (no fast forward) This creates a single merge commit that points to two parents -- the previous commit on master and the latest commit on jira/SOLR-445. It will preserve the history of commits on jira/SOLR-445 (exact hashes of those commits you made, etc.). 2) git merge (fast forward) If there were no intermediate commits on master since you branched jira/SOLR-445 the merge commit is not strictly necessary -- you can simply move the label of 'master' to the latest commit in jira/SOLR-445. This would also preserve all the commits you made on jira/SOLR-445, but you would no longer clearly "see" the branch-merge deviation from the master "line". Try gitk --all if you don't know what I mean. 3) git merge --squash this is effectively taking a diff of all the commits that happened on jira/SOLR-445 since it was branched from master, and this diff is applied to master as a single commit. There is no "record" of where the patch comes from (unless you leave the default commit log, which includes commit hashes, but they don't mean a thing if you remove jira/SOLR-445). > is a regular "git merge --no-squash" prefered for some reason i'm overlooking? 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. 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). Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org