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
