lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Git Policy/Preference: how to fold in feature branches? squash?
Date Fri, 25 Mar 2016 16:59:23 GMT

: 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"


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message