On 08/21/2015 02:28 PM, Andreas Schwab wrote:
Jason Merrill <ja...@redhat.com> writes:

I would expect feature branches to merge from trunk when needed during
development.  When merging the feature into trunk the developer can just
use git merge --squash and then decide whether to commit it in one hunk or
several.

This will of course lose the history of the feature branch.

Yep.  Merging vs. squashing is a subject of debate.

Keeping the history of the feature branch is both a pro and a con: it feels bad to throw away history, but keeping it makes both browsing and bisecting more complicated.

Hmm, it occurs to me that a squash commit (or series of commits) followed by a merge -s ours could have the advantages of both approaches: the patches land on trunk in a sensible order, but the history is available. I wonder if that avoids the bisect complications?

Jason

Reply via email to